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DISCLAIMER 


This book is a training document and contains simplifications. 
Therefore, it must not be considered as a specification of the 
system. 

The contents of this document are subject to revision without 
notice due to ongoing progress in methodology, design and 
manufacturing. 

Ericsson assumes no legal responsibility for any error or damage 
resulting from the usage of this document. 

This document is not intended to replace the technical 
documentation that was shipped with your system. Always refer to 
that technical documentation during operation and maintenance. 


© Ericsson 2009 


This document was produced by Ericsson. 

• It is used for training purposes only and may not be copied or 
reproduced in any manner without the express written consent 
of Ericsson. 

This Student Book, LZT 123 9083, R1A supports course number 
LZU 108 7377 . 
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1 Introduction 


Objectives 



Recognize MSC-S Blade Cluster advantages in GSM and 
WCDMA networks. 


■ Recognize the network architecture and components of the 
GSM/WCDMA network according to system documentation. 



Figure 1-1: Objectives 
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INTRODUCTION 

MSC Server Blade Cluster (MSC-S BC) is the evolved version of 
Ericsson’s Mobile Softswitch Solution’s (MSS) MSC Server 
(MSC-S) providing a high-capacity, fully-scalable and future-proof 
solution offering a smooth migration path towards IMS. 

In its nature MSC-S BC is built upon a scalable architecture, which 
combines the modern Integrated Site (IS) hardware concept based 
on a high-available blade architecture with the strength of 
Ericsson’s well-established MSS solution. 

This chapter shows the network view of an MSC-S BC 
introduction in an existing circuit switched core network and the 
connection towards 2G and 3G radio network. 

MSC-S Blade Cluster is supported for markets following the ETSI 
standard for WCDMA and GSM. 

Ericsson takes the MSS one step further by introducing MSC-S 
Blade Cluster. With MSC-S Blade Cluster, the server capacity is 
increased substantially, supporting up to 8 Million subscribers with 
only two single-depth cabinets, as well as significantly increasing 
the node availability. This allows an impressive network 
simplification and creates a network infrastructure that is easy to 
manage, always available and capable of adjusting to unpredictable 
future traffic increases and changing business needs. 

MSC-S BLADE CLUSTER KEY BENEFITS 

■ Ultra high capacity: 

- up to 3 Million subscribers (MSC-S Blade Cluster Phase 1 ) 

- up to 8 Million subscribers (MSC-S Blade Cluster Phase 2) 

■ Outstanding system availability 

- zero down time on node level 

- enabling SW upgrade of single blades without traffic disturbance 

■ Easy scalability* 

- in steps of app. 500k subscriber by adding new blades 

- Blades can be added and removed without updating the configuration 
of neither radio nor core network. 

■ Future proof solution 

- Blades are generic process (GEP) boards that can be loaded with 
MSC-S software application as well as other applications like e.g. IMS 

- Enabling SIP/SIP-I inter-working* 

*Note: the full implementation of this will be achieved from MSC-S Blade 
Cluster Phase 2 onwards) 


Figure 1-2. MSC-S BC Key Features 
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LAYERED NETWORK ARCHITECTURE - MOBILE 
SOFTSWITCH SOLUTION 


The main Mobile Softswitch Solution (MSS) functions can be 
subdivided into a part belonging to the network control layer and a 
part belonging to the connectivity layer implemented by the logical 
nodes MSC Server and MGw respectively. 


Figure 1-3 below gives an overview about the logical entities of the 
Ericsson WCDMA/GSM core network as part of layered network 
architecture for the CS domain based on 3GPP Release 6. The 
shaded nodes are part of the CS domain. Not all interfaces are 
shown in order to keep the figure readable. 
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Figure 1 -3. Layered architecture network overview 


Note that nodes belonging to transport network, like Signaling 
Gateways (SGW), are not shown. 

In addition to the network connections already mentioned 
connections to corporate access with PRA and connections to 
external networks like TSS, PSTN/ISDN networks and legacy 
networks are shown. 

A short description of the Core nodes and some other important 
PLMN nodes is given below. 
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In the next diagram, figure 1-3 shows the MSC-S BC. It replaces 
the MSC-S/TSC-S and GMSC nodes showed in the figure 1-2. 


MSC SERVER 

A Mobile Services Switching Center Server (MSC Server) 
encompasses the network control layer part of the MSS. It is 
responsible for signaling only. It controls one or more M-MGw 
nodes by means of the GCP protocol. The MSC Server terminates 
the A-interface towards the GSM RAN, the IuCS interface towards 
the WCDMA RAN or both at the same time (Dual Access). It 
connects to the SGSN nodes in the PS domain via the Gs interface. 
It provides for a PRA interface and can be connected directly to a 
PABX. Thus the MSC server is characterized by its handling of a 
subscriber access, either a mobile subscriber or a PABX subscriber. 

MGW 

The MGw encompasses the connectivity layer part of the MSS. It 
is controlled by MSC Server nodes via the GCP protocol. The 
MGw is responsible for connections in the user plane. It supports 
media stream resources like transcoders, echo cancellers or 
announcements for speech calls and the interworking function for 
transparent and non-transparent data, video or FAX calls. The 
physical M-MGw node may also include node functions l ik e SGw, 
AAL2 switch, ATM VC or TDM cross connect, which are part of 
the transport layer. 

TSC SERVER 

The Transit Switching Center Server (TSC Server) is part of the 
control layer. It can route a call inside the PLMN network using 
BICC and ISUP signaling. It can also act as a gateway providing 
BICC to ISUP conversion between the PLMN and external 
networks. 

GMSC SERVER 


A Gateway MSC Server (GMSC Server) is part of the control layer 
and is responsible for interrogation to the HLR. A standalone 
GMSC Server extends on the TSC Server functionality by the HLR 
interrogation function. The interrogation function can also be co- 
located within an MSC Server. 
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GSMSSF 

The gsmSSF function entity is always integrated within an MSC 
Server or GMSC Server. This function entity is responsible for 
CAMEL support. 

MGCF 

The MGCF function entity will be integrated within all MSC 
Blades in R14.0. However, there is no specific interface between 
MGCF and TSC server. MGCF function provides control plane 
interworking between Core Network and IMS domain or other 
wireline/wireless softswitches using SIP-I. It also offers the 
possibility to interconnect IMS based networks with other SIP-I 
based VoIP solutions via the TSC Server. 


All SIP/SIP-I functionality will be available in the MSC-S BC R14 
and on. 

IM-MGW 

The IM-MGw function entity may be standalone or integrated 
within an MGW. IM-MGw function provides user plane 
interworking between CNCS and IMS domain or other 
wireline/wireless softswitches using SIP-I. 

DNS 

DNS is an Internet directory service. DNS is used to determine the 
IP address, server port and transport protocol from a domain name. 

OSS-RC 

OSS-RC supports sub-network management (SNM) functions for 
the CS core network. In addition also the PS domain nodes and 
other PLMN nodes like HLR/FNR are managed by OSS-RC. 

SMS NODES 

The two logical SMS nodes SMS-IWMSC and SMS-GMSC can be 
co-located with an MSC Server. However, in most cases they are 
not used since most SMS Service Centers (SMS-SC) are equipped 
with integrated SMS-IWMSC and SMS-GMSC functions. 
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INTERNET ACCESS SERVER 

This is a 3PP node providing access towards the public Internet. 
The connection between the Internet Access Server in layered 
network architecture is via ISUP and TDM transport. 

LEGACY SUPPORT NODE 

Server nodes do not support conversion of legacy protocols like 
TUP or CAS to BICC. Therefore a separate node is used converting 
these legacy protocols to ISUP first. 

The Ericsson Legacy Support Node is implemented by means of a 
TSC of the non-layered network architecture in most of the cases. 

HLR/FNR/AUC/EIR 

The Home Location Register (HLR) database stores and manages 
all mobile subscriptions belonging to a specific operator. The HLR 
stores permanent data about subscribers, including subscriber’s 
supplementary services. 

The database Authentication Center (AUC) is connected to the 
HLR. The function of the AUC is to provide the HLR with 
authentication parameters and ciphering keys. The AUC protects 
network operators from fraud. 

The Llexible Numbering Register (LNR) provides mobile 
subscribers the ability to change network operator retaining the 
original directory number. The LNR Application reroutes messages 
to the appropriate HLR. 

The Equipment Identity Register (EIR) provides a means for the 
network operator to control access to his network for specific 
MS/UE through the maintenance and interrogation of multiple lists 
ofIMEIs. 


MSC SERVER BC ARCHITECTURE OVERVIEW 

The MSC Server BC provides mobile telephony functions based on 
a scalable cluster of MSC blades. 

The high-level architecture of the MSC Server BC is shown in 
figure below. The figure depicts physical connections between the 
components. 
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Figure 1-4. MSC BC Overview 


The MSC Server BC consists of the following components: 

• MSC blades 

• TSC blades 

• SPX (including RP equipment and SCB) 

• APG-IO, STS and APG-CHS (including SCB) and 

• IS (including ISER, SIS, EXB and MXB) 

The MSC blades offer mobile call control functionality to/from the 
radio network. 

The TSC blades offer TSC Server call control functionality to/from 
the core network. 

The SPX terminates, converts, relays and distributes signalling 
traffic received from the network to the appropriate MSC or TSC 
blade. 

MSC Server BC O&M functionality is provided by APG 
components and the OSS-RC (MSC Server BC external node). 

OSS-RC is an own network node which supports operation and 
maintenance of the MSC Server BC. 
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The IS framework provides the Layer 2 and 3 infrastructure for the 
blades, incorporating ISER, SIS (for O&M of IS infrastructure), 
EXB and MXB components. 

MSC SERVER BC COMPONENTS AND FUNCTIONS 
MSC Blade 


An MSC blade is a single sided, IS-adapted blade, configured to 
offer the following logical functionality: 

• MSC Server 

• GMSC Server 

• SMS-IWMSC 

• SMS-GMSC 

• SSF/gsmSSF 

The MSC Server BC uses the N+l redundancy concept to protect 
MSC Server applications against (single) blade failure. The N+l 
redundancy is implemented by the use of a primary MSC blade and 
a buddy MSC blade for each registered mobile subscriber. At 
(single) blade failure, all remaining MSC blades share the 
compensation of the unavailable MSC blade. 

A primary MSC blade is one from two MSC blades that can handle 
a certain mobile subscriber. One of the MSC blades in the MSC 
Server BC is automatically selected as primary MSC blade for each 
mobile subscriber by the mobile subscriber distribution function. 
The primary MSC blade executes traffic for a mobile subscriber 
unless it experiences a transient failure or traffic isolation. 

A buddy MSC blade is one from two MSC blades that can handle a 
certain mobile subscriber. One of the MSC blades in the MSC 
Server BC is automatically selected as buddy MSC blade for each 
mobile subscriber by the mobile subscriber distribution function. 
The purpose of the buddy MSC blade is to handle new traffic for a 
subscriber during traffic isolation or a transient failure of the 
primary MSC blade of the same subscriber. 

From the two MSC blades that can execute traffic for a mobile 
subscriber (primary MSC blade and buddy MSC blade), a blade 
that actually handles the subscriber is the active MSC blade. The 
other one is the passive MSC blade. 


LZT 123 9083 R1 A 


© Ericsson 2009 


- 17 - 





MSC-S R13.1 Blade Cluster Data Transcript 


ERICSSON ^ 


During traffic isolation or at a transient failure, an MSC blade, by 
default, becomes a passive MSC blade for all mobile subscribers 
that are already registered on that blade. 

Mobile originating calls towards external nodes are routed from the 
active MSC blade to a TSC blade based on the consistent cluster 
view. Mobile originating calls towards mobile subscribers served 
by another MSC blade are routed to this MSC blade. Mobile 
originating calls towards mobile subscribers served by the same 
MSC blade are handled by one and the same MSC blade. 

The VLR data replication function makes the subscriber data of a 
mobile subscriber available in the VLRs of the primary and buddy 
MSC blade. In exceptional cases the VLR data replication might 
fail and, for these exceptional cases, consistency of certain data is 
not achieved (weak consistency). Cases of inconsistent data are 
detected and in such cases the stored data are discarded and new 
sets of data are fetched from the HLR and stored in the VLRs of 
the primary and buddy MSC blade to restore the data consistency. 

Each blade is able to route subscriber related initial connection 
requests or dialog requests to the active MSC blade (primary or 
buddy MSC blade) in the MSC Server BC following the 
distribution of subscribers. 

The mobile subscriber distribution function, which is located on the 
MSC blades (each MSC blade has a distribution function), uses 
load vectors to perform distribution of subscribers. A load vector is 
a logical representation of the cluster configuration and the load 
distribution within the MSC Server BC. The information of the 
load vectors is stored on all MSC blades and it is used by the 
distribution function to determine the primary MSC blade and the 
buddy MSC blade of a mobile subscriber. Different load vectors are 
used for this task. The load vectors are calculated based on the 
consistent cluster view information data set. 

A transient failure of a blade is a temporary situation. During this 
situation, the blade is not able to execute traffic due to automatic 
recovery actions. If the primary blade transiently fails, its mobile 
subscribers can be handled by the buddy MSC blade. Once the 
buddy MSC blade has taken the control of a subscriber, it handles 
this subscriber until the next location update is received or until it 
becomes unable to execute traffic due to traffic isolation or due to a 
transient failure. At the occurrence of one of these events, the 
primary MSC blade will start to handle the subscriber again, unless 
the primary MSC blade is not able to execute traffic. 
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A permanent failure of an MSC blade is a failure that cannot be 
corrected by automatic recovery actions. A permanent failure of an 
MSC blade always leads to a cluster reconfiguration. New load 
vectors are calculated to reconfigure the cluster. 

When traffic isolation is initiated, no new traffic is distributed to 
the MSC blade that is under traffic isolation, but existing traffic 
may be allowed to continue on that MSC blade. An MSC blade is 
traffic isolated when there is no traffic on it and new traffic is 
prohibited, except test calls. Only one blade can be isolated at a 
time. 


TSC Blade 


A TSC blade is a single sided, IS-adapted blade, configured to offer 
TSC Server call control functionality towards the core network and 
the MSC server applications (MSC blades). Its function within the 
MSC Server BC is to provide BICC, ISUP and China TUP 
connectivity towards peer core network nodes. The TSC blade 
terminates BICC, ISUP and China TUP protocols, whereas related 
traffic handling is performed at the MSC blades. 

Based on the consistent cluster view, TSC blades distribute traffic 
with mobile number to the MSC blades. For mobile terminating 
calls with MSRN, calls are routed by the TSC blades to dedicated 
MSC blades based on the mobile subscriber distribution. TSC 
blades are able to handle transit traffic. 

Two TSC blades are used within an MSC Server BC to achieve 
redundancy on network level. 

When traffic isolation is initiated, no new traffic is distributed to 
the TSC blade that is under traffic isolation, but existing traffic may 
be allowed to continue on that TSC blade. A TSC blade is traffic 
isolated when there is no traffic on it and new traffic is prohibited, 
except test calls. Only one blade can be isolated at a time. 

Signalling Proxy (SPX) 

The Signalling Proxy (SPX) is based on a double-sided AXE CP 
with RP equipment and routes signalling traffic (based on TDM, 
ATM or IP) received from external network nodes to the 
appropriate MSC blade or TSC blade. 

The main purpose of the SPX is to hide the blades from external 
network nodes. 
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For load sharing purposes, redundancy reasons and to avoid 
disturbances when software is updated on an SPX, two SPXs are 
used within an MSC Server BC. 

Two SPXs achieve redundancy on network level, if remote peer 
nodes can be connected to both SPXsl. 

All external, traditional SS7 signalling (MTP) and in addition 
M3UA/SCTP/IP is handled by these two SPXs, that is the SPX 
terminates and converts external signalling transport (SCCP/MTP 
to SUA/SCTP/IP or MTP/ATM, MTP/TDM to M3UA/SCTP/IP) 
within MSC Server BC. SUA/SCTP/IP and M3UA/SCTP/IP may 
be terminated and converted back to SCCP/MTP or MTP at the 
SPX for signalling transport towards external network nodes. 
M3UA/SCTP/IP may be relayed by the SPX. Except for SCCP as 
M3UA user, M3UA/SCTP/IP can optionally be connected directly 
to the blades, bypassing the SPX. 

The SPX (including SCB) is connected by a layer 2 switch (EXB) 
and IS equipment (including MXB) to MSC blades or TSC blades. 

SUA Signaling and other signaling issues will be detailed later on 
another chapter. 

MSC Server BC O&M (APG and OSS-RC) 

For the Operation and Maintenance (O&M) of the blades and the 
signaling proxies, at least two APGs are needed. One APG is meant 
for MML-IO and statistics, including back-up and reload. The 
second APG collects charging and accounting data from all the 
blades and the signalling proxies. SCCP and MTP accounting data 
are collected from both signalling proxies separately. 

The MSC Server BC is administered via MML commands which 
are executed in each blade. 

IO-Commands may address a specific blade or SPX, any subgroup 
of blades and SPXs (multicast) or all the blades and SPXs at once 
(broadcast). As soon as more than one single blade or a single SPX 
is addressed by an IO-command, a printout comparison function in 
APG, ensures that only one printout is provided, if the same 
printout is received from all addressed elements. 

The Network Element Header, preceding the prompt or any result 
printout, carries the CP blade name or CP group name to specify 
the printout data origin. 
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The Network Element Header, preceding any spontaneous alarm 
printout carries the CP blade name to specify the printout data 
origin. 

The element manager (WinFIOL 7.1 or higher) extends the 
command dispatcher and the printout comparison function 
provided by APG. 

Integrated Site (IS) Infrastructure 

The IS infrastructure consists of the following elements: 

• SIS 

• ISER 

• MXB and 

• EXB 

It provides the main on site protocol layer 2 infrastructure for the 
MSC Server BC. 

The IS is using Ethernet on the backplane for signalling traffic. 

The Site Infrastructure Support System (SIS) enables booting and 
O&M (set-up and operation) of layer 2 infrastructure and 
components (as ISER). Two SISs are used to provide network 
redundancy. 

The ISER connects the MSC Server BC to the IP network of the 
site. Two ISERs are used to provide redundancy. 

IS uses layer 2 switches (MXB and EXB) and ISER to enable 
connectivity. Two EXB (used for IS-external linkage) and two 
MXB (used for IS-internal linkage) layer 2 switches are used to 
provide network redundancy. 

EQUIPMENT (HARDWARE) MANAGEMENT 

Figure below shows an overview of the MSC-S BC hardware. Note 
that this is only an example of one possible HW configuration 
(large configuration). 


LZT 123 9083 R1 A 


© Ericsson 2009 


- 21 - 





MSC-S R13.1 Blade Cluster Data Transcript 


ERICSSON 



[] SPX 

□ 'o 

I I TDM Option 
| ATM Option 


I | IS Infrastructure 
01 MSC-S Blades 



Figure 1 -5- HW overview of one of the MSC-S BC Node configurations 

The recommended tool for making initial HW configurations and 
to configure the IS O&M Domain is the ISM GUI. In the ISM GUI 
it is possible to view and to make initial configurations for all 
Blade Systems in the node. 

After initial configuration of the MSC-S Blade System further APG 
O&M Domain HW configurations are to be done via WinFIOL. 
The application configurations can also be done from OSS. 

SOFTWARE UPGRADE 

The different Blade System, and Attached System (SPX and APG), 
entities have their own dedicated upgrade (and update) procedures 
and basically each entity have to be upgraded separately. Generally, 
the upgrade of the IS parts shall be done prior to the upgrade of the 
MSC parts. 

The different Blade Systems and Attached Systems (SPX and APG) 
can be upgraded individually by means of their dedicated Element 
Managers. However, for the upgrade of the IS O&M Domain 
components it is recommended to use the ISM-UI, and for the 
upgrade of the APG O&M Domain, the OSS-RC Software 
Management Organizer (SMO) shall be used. 
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The ISM-UI provides support for downloading and changing 
software for the blade systems, however not for the blade systems 
belonging to the APG O&M Domain. 

The OSS-RC SMO application provides support for the software 
transfer to the node and support for automated upgrade of the 
whole APG O&M Domain by means of OPS Scripts. The OPS 
scripts are run in the SMO either directly or at a later scheduled 
point in time. The progress is shown in SMO. 


NODE BACKUP 


From backup point of view, the IS O&M Domain software and the 
APG O&M Domain software have to be handled separately. 

The IS O&M Domain can be backed up from the ISM-UI onto SIS. 
The backup contains only the configuration data and it can be made 
for only one Blade System at a time or for the whole IS site in one 
go. However, the Site backup will not contain a full APG O&M 
Domain backup. The backups are normally stored on the node but 
can also be sent further to external media by for example sftp. For 
more information about IS part backup see reference. 

Backups for all APG O&M Domain components (MSC, SPX, TSC 
and APG) can be initiated from APG or from the OSS. In any case 
the backups will be handled by, and temporary stored on the APG. 
Each APG O&M Domain component will have its own backup file 
which is stored in its corresponding directory in APG. From the 
APG the backup files can be sent to an external media or server. 

CONFIGURATION MANAGEMENT 

The MSC-S BC node consists of the IS and MSC parts which are 
handled separately. Figure gives a high level view of this. 
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Figure 1-6- IS and MSC parts of the Configuration Management for the 
MSC-S BC node. 

The IS parts are the SIS, ISER, MXB and EXB. These are 
configured through the IS O&M Domain or the SIS. However, also 
the MSC BS contain some IS Infrastructure related functionality 
that has to be configured through the IS O&M Domain. The IS 
parts are configured either from an Element Management tool or 
from the ISM-UI. Some configuration tasks can only be performed 
using an applicable Element Management tool such as the CLI for 
ISER. 

The APG O&M domain is configured through the APG in the 
MSC-S BC. They are configured either from an Element 
Management tool (WinFIOL) or from the OSS-RC. Basically, each 
blade is seen as a separate entity or “node”, it has its own 
configuration data and has to be individually configured. Generally, 
the recommendation is to keep the exchange data as equal as 
possible between the entities. That is, to define the same exchange 
data in all entities whenever applicable. 

The DT course deals with this configuration, on MSC and TSC 
Blades and SPXes. 
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In order to ease the configuration of the MSC blades, and in order 
to keep the system more homogenous, a command dispatcher 
function is provided. With this function it is possible to configure 
MSC blades into CP groups. When a command is executed towards 
this group the command dispatcher copies and distributes the same 
command to all blades in the CP group. Each blade processes the 
command and replies to the dispatcher which collects the replies 
into one single answer. In case of deviations in the replies from the 
different blades, all replies will be included into the answer. 

The command dispatcher function can be configured to cover also 
the TSC blades and SPXs, but maybe not always recommendable. 
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2 Introduction to Data Transcript 


Objectives 


Understand the Data Transcript process according to 
system documentation. 

■ Explain the inputs and outputs of the Data Transcript 
process. 

■ Use the Customer Product Information (ALEX 
Document Browsers) in order to find appropriate 
commands, parameters and parameter values. 






Figure 2- 1 . Objectives 
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INTRODUCTION 

Data Transcript is one of the activities required in the development, 
design and testing phases of producing a new product before it can 
be released. This product could be a new telephony application or 
extra functionality added to an existing application. Data Transcript 
is the process of producing Man-Machine Language (MML) 
commands. These MML commands are subsequently entered into 
an AXE telephone switch, allowing the AXE- switch to realize the 
designed functionality. Some of the commands will be the same in 
all AXE telephone exchanges, but many of the MML-commands 
will be different; differing for a number of switches running the 
same application, as well as switches running different 
applications. 

The input requirements for any data transcript activity are 
principally the same for all telephony applications supported by 
Ericsson. The rest of the modules will look at the data transcript 
required for the mobile application. The data transcript will be built 
up on call types. 

Figure 2-2 identifies the inputs and outputs required for the ‘Data 
Transcript Process’. After the figure there is a description of each 
input and output. 



Figure 2-2: Input and Outputs of the Data Transcript Process 
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C3 FILE 


The C3 file contains the allocation data relating to the “hardware” 
being installed. This information becomes subfile 20000. This 
subfile will define: 

• The Regional Processors and the related software - EXRPI 
and EXRUI 

• The Extension Modules - EXEMI 

• The Group Switch - GDCOI (for classic MSC mainly) 

• The Switching Network Terminals and the connection of 
the hardware - NTCOI and EXDUI 

• The position of the hardware might be included - EXPOI 

It can be seen from Figure 2-2 that the Installation Engineering (IE) 
supplies the C3 file. This C3 file will be unique for every switch 
being installed. 

It is important to remember that certain commands, such as GDCOI 
and NTCOI have parameters (VAR for GDCOI and SNTV for 
NTCOI), where the value is dependent on the hardware being used. 
The software uses these parameter values when the hardware is 
being tested. 

In the Application Information (AI) the correct parameter value 
will be found. This value will be used to carryout different test 
routines. Parameter values are specified by the IE department and 
should be correct. However, it is a good idea to compare these 
values against those specified in the AI against the hardware to be 
installed as described in the ‘Floor Plan Specification’. 

Note: The Group Switch is an optional hardware in the MSC-S 
Blade Cluster solution and it is applicable only for SPX nodes. In 
fact it is just used in case TDM and/or ATM signaling in the MSC- 
S node is needed. Then, other hardware will be necessary as well 
such as STEB (narrowband/broadband TDM signaling board), 
ALI-E (ATM signaling board). 
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NETWORK AND EXCHANGE REQUIREMENTS 

The network operator will place certain requirements on the 
software. These requirements can be divided into Network 
Requirements and Exchange Requirements. 

NETWORK REQUIREMENTS 

Network requirements will have been specified by the customer 
and will be on the reference dumps delivered to the site. For 
example, the network requirements could identify the frequency of 
the tone received for dial tone, or the inter-digit timeout. It could 
also affect certain changeable exchange parameters. 

EXCHANGE REQUIREMENTS 

Exchange Requirements (ERs) are unique to a switch and will 
determine how the exchange will fit into its environment. The ERs 
could be identified in a number of different ways. This course will 
show different examples and how they can be documented. An 
example of the simplified ER Form is shown below. 

The ER form contains the minimum information required to 
produce the data transcript for a particular exchange and is 
collected from the operator prior to the Data Transcript been 
produced. The information will identify: 

• The network and node Identification (signaling point codes etc) 

• Naming Conventions. 

• Which other nodes it interconnects with, both within the PLMN and 
PSTN 

• The number series used within the PLMN 

• The number series of the test phones (BL-phones) (for classic MSC 
nodes) 

• Special number series in the PLMN/PSTN 

• International roaming agreements 

• Other equipment 
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The information contained within the ER form will include general 
data relating to a particular network operator and specific data for 
the new node, which is to be installed and brought into service. 
These forms will need to be completed for each new node being 
added to an existing network. If it is a new network, several of 
these forms will be required. 

The end result will be the production of the MML (subfiles) 
required to bring the exchange into service. 


1317 LIST 


The 1317 List (Product Document List) is a document, which gives 
information about the products used in the application. Lor 
example, the product code for the APT source system would be 
identified. This product code would then be used to identify each of 
the subsystems by their name and their product number. Each 
subsystem is made up of a number of function blocks, again 
identified by name and product number. The function blocks are 
made up of function units. Again, their name and their product code 
identify these. 

This document can also be used to find the correct Application 
Information document for a function block, as the 1317 List 
contains the product name as well as the product code. 

Ligure 2-3 shows an example of the product name, as well as the 
product code. The most interesting part, for example, would be the 
section showing the function block and then identifying the 
function units, which make up that particular function block. 
Notice that the two software function units, identified by CAA, 
have ‘U’ or ‘R’ at the end of their product name to identify that it is 
either Central or Regional software, respectively. Also note that the 
hardware, identified on this occasion by ROE, is realized by one of 
three Printed Circuit Boards (PCB); any one of them could be used. 
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C INCLUDED PRODUCT GROUPS 


MAIN 

AXE 

106 

30/6 =R1A 

2 /AXE 

2 /AXE 106 30/A46 =R1A 

MAGAM 

APR 

101 

49/7 =R1A 

BTAM 

APR 

101 

36/3 =R1A 

IUSAM 

APR 

101 

20/14 =R1A 

LSS 

ANT 

314 

01/11 =R1A 

MDS 

ANT 

294 

02/13 =R1A 

MMS 

ANT 

293 

01/17 =R1A 


— C — 
MMS 


•PRODUCT GROUP: MAGAM 


ANT 293 01/17 =R1A 


MRALT 

CNT 293 0349 =R1 

MRALTU 

CAAZA 107 2158 =R1A 

MRALTM 

CNT 293 0349 =R1 

MRALTMU 

CAAZA 107 2158 =R1A 

MALT 

CNT 293 0363 =R1 

MALTU 

CAAZA 107 2239 =R1A 

ETMALT 

CNT 212 2198 =R7 

ETMALTU 

CAAZ 107 2913 =R5A 

ETMALTR 

CAA 135 3024 =R3A 

ETC5 

ROJ 204 03/1 >R3A 


Figure 2-3: 1317 List Product Code List 

Example of using the 1317 List 

In the network we shall be using Mobile Telephony Remote A 
Interface Terminal (MRALT). To find the correct document 
(Application Information) you need to know the device name or 
function block, the 1317 list can then be used to find the product 
code for the device type. Using the product code the A.I. for the 
correct block can be found. 

The Application Information will give the corresponding block 
information, e.g. Size alteration event (SAE’s), function codes 
(FNC)...The device type can also be obtained from the A.I. this is 
the device specified in the route definition: 

EXROLR = DETY =MRALT; 

Function block MRALT is part of the Mobile Mobility and Radio 
Subsystem (MMS) in Mobile Access and Gateway Application 
Module (MAGAM). 
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AXE PRODUCT STRUCTURE 

The AXE product is divided into different sub-levels. 



FLOOR PLAN SPECIFICATION 

The ‘Floor Plan Specification’ is a document, which identifies the 
position a magazine has been allocated in a cabinet. This document 
also identifies, if applicable, the RP and EM designations of the 
hardware concerned. The product code of the hardware is useful 
when trying to find parameter values for the exchangeable 
exchange data, which are hardware dependent. The changeable 
exchange data is found in the Application Information for the 
specified function block. The Floor Plan and the C3 file should 
have identical information. 


EXCHANGE DOCUMENTATION 

The majority of operators use the Windows based program ALEX 
(AXE Library Explorer) in order to view the exchange 
documentation. ALEX can be installed locally on a Windows PC or 
on a server with access over the Internet or Intranet. The document 
books can either be stored locally on the computer or on a server. A 
browser, such as the Internet Explorer or Netscape is used to view 
the information. 
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Figure 2-5: Active Library Exchange - Alex Documentation Browser 

LIBRARY SURVEY (A-MODULE) 

The Library Survey contains general information. In earlier syntax 
it was called the A-Module. 

OPERATION & MAINTENANCE (B-MODULE) 

The Operation and Maintenance Module will be the document that 
will probably be referenced the most. In earlier syntax it was called 
the B -Module. The B -module contains the following types of 
documents: 


Operational Instructions - OPI 

OPI is a set of instructions outlining the correct procedures to 
follow for operation and maintenance of the exchange. 

OPI has a decimal class of 15 431. 


Command Description - COD 

Every command used in the application will be available. COD will 
show which parameters are to be used and which are optional. 

COD has a decimal class of 19 082. 
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Printout Descriptions - POD 

All Printouts that are obtained from the exchange will have a 
corresponding printout document. This could be useful to identify 
fault codes, for example. 

POD has a decimal class of 19 083. 

Adaptation Direction - ADI 

ADI often has a more detailed explanation of the commands and 
parameters than that found in COD. This is a useful document if a 
more in-depth understanding of the command flow is required. 

ADI has a decimal class of 15 542. 

Application Information - Al 

There is an AI for all function blocks that have changeable 
exchange data. This is a very important document that will contain 
the majority of the information required when specifying 
application specific information. 

AI has a decimal class of 15 518. 

SYSTEM DESCRIPTION (D-MODULE) 

The D-module contains descriptions of the application from system 
level 1 at a very high level down to a function block level. This 
would usually be used for reference information only. 


E-MODULE 

The E-module contains all of the software, in Programming 
Language for Exchanges (PLEX) and Assembly Language (ASA). 
This module will be referenced to find the Permanent Exchange 
Data. The E-Module is generally not available for the network 
operator. 

I-MODULE 


The I-module contains all the data transcript files for the MSC-S 
BC start-up. This module is used by the deployment staff. 
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■ Library Survey (A-Module) 

■ Operation & Maintenance (B-Module) 

- Operational Instructions (OPI) 

- Command Descriptions (COD) 

- Printout Descriptions (POD) 

- Application Directions (ADI) 

- Application Information (Al) 

■ System Description (D-Module) 

■ E-Module (Plex and ASA) 

■ 1-Module (DT files) 

Figure 2-6: Alex Structure 


PERMANENT AND CHANGEABLE EXCHANGE DATA 

The Exchange Documentation will be used to find both the 
Changeable Exchange Data and the Permanent Exchange Data. 

PERMANENT EXCHANGE DATA 

The E-module will be required to find the Permanent Exchange 
Data, the values of which are coded in the software, and can be 
found in the parameter lists. 

CHANGEABLE EXCHANGE DATA 

The B-module is used to find the Changeable Exchange Data. 
COD and ADI will be used to find which parameters are needed for 
a particular command, while AI will be used to find the correct 
parameter value for a parameter whose value is application 
dependant. 

REFERENCE DUMP 

The reference dump consists of the software for both the APZ and 
APT products as well as minimal exchange data to support the 
loading of the dump onto a new switch. The exchange data 
includes only APZ related information. For example, size 
alterations (SAE), the definition of SPG 0 (for IOG) or API (for 
APG40) and also certain Alphanumeric Terminals (ATs) / 
Alphanumeric Devices (ADs) will be defined in the 10 table. 

For the dump to be useful, the MML-commands for the APT 
application also need to be loaded. The information is contained in 
a number of subfiles. 
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Examples of the subfiles are shown below: 


Subfile Number 

Name 

9000.001 

Mobile Telephony Feature Activation 

10000.001 

Size Alteration Events (SAE) 

12000.001 

Signaling Point and Supervision 

13000.001 

Mobile Telephony Exchange Properties 

15000.001 

End of Selection 


Figure 2-7: Example of DT Subfiles 

Subfiles are simply a group of commands that implement one or 
several similar functions. Collectively the subfiles form the I- 
Module (the complete data transcript file). 

The subfiles will then be loaded onto the exchange from a terminal. 
In the previous figure shows just some of the APT data transcript. 
In fact, there will also be a need for creating subfiles to bring the 
equipment into services. 

WORKING DUMP 

The output of the data transcript process, the MML commands, 
combined with a reference dump form the working dump. This 
working dump is unique to each exchange within a network. 
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3 Classic Routes and Signaling Circuits 


Objectives 



MSC-S Blade Cluster Classic routes and signaling 
circuits 


■ Check the hardware definition for TDM narrowband and 
broadband signaling 

■ Verify the routes types in the MSC-S 



Figure 3- 1 . Objectives 
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INTRODUCTION 

This chapter will use the Exchange Requirement (ER) forms, 
identifying to which nodes MSC is connected. This will include 
nodes to other networks as well as other nodes within the Home 
PLMN. By the end of the module the data transcript for connecting 
the speech and the signaling circuits will have been covered. 

Much of the information in this chapter will have been discussed in 
previous AXE courses, and should therefore be a repetition. The 
beginning of this chapter contains sections, which should be 
familiar, while other areas might be new. The MML-commands 
needed to set up speech and signaling circuits are at the end of this 
module. 


TYPES OF SIGNALING 

“Signaling” refers to the transfer of control information either from 
a subscriber to an exchange or from one exchange to another. The 
purpose of signaling is to set up, supervise and disconnect 
telephone calls. 

Signaling can be divided into two main categories: Subscriber Line 
Signaling and Inter- Exchange Signaling. In this module, we will 
focus on the Inter-Exchange Signaling, which involves signaling 
between exchanges. It is divided into: 

• Channel- Associated Signaling (CAS). 

• Common-Channel Signaling (CCS). 

Figure below identifies the signaling used between MSC-S Blade 
Cluster and other nodes and networks. The signaling transport 
between MSC-S BC and the nodes are based on IP (SIGTRAN) an 
internally also IP (SUA/SIGTRAN). This subject will be treated 
later on. 

The ISUP and BICC for example signaling protocol requires the 
Common Channel Signaling System No. 7 (C7 or SS7) to transport 
their message from one node to the other node. 
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CHANNEL ASSOCIATED SIGNALING 

In channel-associate signaling, signaling is done in the speech 
channel itself (in-band) or in a channel closely (out-band) 
associated to the speech channel. Signaling and speech must take 
the same path through the network. 

CAS uses in-band and out-band signals (in time slot 16 of the PCM 
system) to send information between two nodes. The information is 
sent using ‘Line Signals’ or ‘Register Signals’. 

Line Signals can only use time slot 16 and can occur at any time 
during a call. An example of a line signal would be a SEIZURE 
SIGNAL. 

Register Signals are used during the call set-up phase and take 
place over the timeslot allocated for the call. Register signaling has 
several different variants, some requiring extra hardware while 
some have the register signaling realized in the ETC. R2 MFC is a 
type of register signaling specified by the CCITT. An example of a 
register signal would be the sending of the B-Number. 


R2 Signaling 


R2 signaling is based on the Multi-Frequency Compelled (MFC) 
method, that is, the combination of two different frequencies to 
uniquely identify some information, for example a B -number. It 
will in future be referenced as R2 MFC. 

To support R2 MFC signaling, extra hardware is required in 
addition to the ETC, which terminates the PCM system. This extra 
hardware is a Code Sender and Code Receiver (CS & CR) or a 
combined Code Sender and Receiver (CSR). The CS is used to 
send the R2 MFC signal from the originating exchange, whereas 
CR is used to receive the R2 MFC signal at the destination 
exchange. CSR is a combined piece of hardware, which allows it to 
act as a CS or CR depending on the direction of the call. 
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COMMON CHANNEL SIGNALING SYSTEM NO. 7 

The Common Channel Signaling System No. 7 (C7) is a method of 
transferring signaling information between two signaling points. 
The signaling is performed over separate channels. It is divided 
into two main parts, with one part MTP (Message Transfer Part) 
which takes care of message transfer and another part UP (User 
Part) which is responsible for the exchange of these signaling 
messages). The following are some of the MTP user parts: ISUP 
(ISDN User Part), MAP (Mobile Application Part) and BSSAP 
(Base Station System Application Part). To support MAP, BSSAP 
and RANAP, SCCP (Signaling Connection Control Part) is needed, 
and also TCAP (Transaction Capabilities Application Part) is 
needed for the MAP. 

The information, which is sent from one signaling point to another, 
could be related to a particular 64 kbps circuit. It could also be 
used to transfer information between two nodes not related to a 
circuit. 

Circuit related signaling messages would typically be the setting up 
of a telephone call using ISUP. 

Non-circuit related messages would be sending information related 
to a call already set up such as ISUP or checking subscriber 
information using MAP. 



Figure 3-2: Component of Common Channel Signaling No. 7 

Message Transfer Part 

The purpose of MTP is to transfer information from one node to 
another, in a reliable way, ensuring that the message is received 
without any corruption, in the correct sequence and to the correct 
destination node. MTP has to provide the following five functions: 
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• Error Detection 

• Error Correction 

• Discrimination 

• Distribution 

• Routing 

MTP is made up of three parts: the Signaling Data Link, the 
Signaling Link and the Signaling Network as shown in below. 



Figure 3-3: Components of the Message Transfer Part 

• The Signaling Data Link is a bi-directional transmission path 
for signaling. In a PCM system using 32 channels, any of the 
64 kbps circuits can be used as the signaling data link except 
time slot 0. ER will tell you which time slots to use. 

• The Signaling Link provides a reliable link between two points 
directly connected together, transferring the signaling message 
between each point. The signaling link performs error detection 
as well as error correction on the signaling message being 
retransmitted. 

• The Signaling Network is made up of the following two 
functions: the Signaling Message Handling and the Signaling 
Network Management. The Signaling Message Handling 
carries out message discrimination, message distribution and 
message routing. The Signaling Network Management controls 
the signaling traffic in case of congestion in the signaling data 
link. 

The signaling message sent between two signaling points is carried 

in a Message Signal Unit (MSU). MSU is shown in the next figure. 
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Figure 3-4: Contents of a Message Signal Unit 

Since there are several users of MTP, for example, ISUP and SCCP, 
they can all send their signaling message using the same C7 
signaling link. Therefore, a method is required to identify the user 
of MTP To help the signaling message handling function distribute 
the message to the correct user, MSU contains a Service Indicator 
(SI) parameter which identifies the User of MTP In Figure 3-5 the 
user of MTP is ISUP The SLS values are used to distribute the load 
inside the Link Set (LS). 

The Originating Point Code (OPC) identifies the originating 
signaling point of the message. The Destination Point Code (DPC) 
identifies the destination of the message. The TUP message relates 
to the 64 kbps circuit identified by the Circuit Identification Code 
(CIC). The Network Indicator (NI) identifies the signaling network 
to which this signaling belongs. 

The SS7 (ANSI standard) messages format differs in length and an 
extra Message Priority field. 

The commands to define MTP are shown in Figure below. 


1. Own Signaling Point: 

C70PI , 

C7PNC. 

2. Signaling Points in Different Networks: 

C7SPI, 

C7PNC. 

3. C7 Signaling Terminal Identity 

C7STI . 


4. Definition of Link Set: 

C7LDI . 


5. Definition of Signaling Links: 

C7SLI . 


6. C7 MTP Routing: 

C7RSI . 


7. Signaling Route Definition: 

EXROI . 


8. Semi-Permanent Connection: 

EXSPI , 

EXSSI EXSPE 


Figure 3-5: Commands Defining the MTP Traditional SS7 Signaling 
Definition using TDM 
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Follow some command comparison about ITU-T/ANSI standards: 



Command (ITU-T 
and TTC signaling) 

Command (ANSI 
signaling) 

Description 

Signaling 

point 

C7SPP:SP=sp; 

S7DEP:DEST=dest; 

OWNSP, SP DATA 

MTP 

C7RSP:DEST=dest; 

S7RSP:DEST=dest; 

Data, STATE 

Routing 

C7RAI/C7RAE:DEST 

=dest; 


Activation/Deactivation 


C7RUP:DEST=dest; 

S7DSP:DEST=dest; 

Supervision DATA 

Link Set 

C7LDP:LS=ls; 

S7SLP:LS=ls; 

DATA (LS, SLC, ST, SPID) 


C7LTP:LS=ls; 

S7LTP:LS=ls; 

STATE 


C7SUP:LS=ls; 


Supervision DATA 

Signaling 

C7LDP:LS=ls; 

S7LDP:LS=ls; 

DATA (LS, SLC, ST, SPID) 

Link 

C7IHI/C7IHE:LS=ls, 

SLC=slc; 

S7IHI/S7IHE:LS=ls, 

SLC=slc; 

Inhibiting/Uninhibiting 


C7LAI/C7LAE:LS=ls, 

SLC=slc; 

S7LAI/S7LAE:LS=ls, 

SLC=slc; 

Activation/Deactivation 

Signaling 

C7STP:ST=C7ST2-x; 

S7STP:ST=S7ST-x; 

DATA (ST, RP/EM, LS, 
SPID, SLC) 

Terminal 

C7TSP:ST=C7ST2-x 


STATE 


C7LDP:LS=ls; 

S7LDP:LS=ls; 

DATA (LS, SLC, ST, SPID) 


BLEMI/BLEME:EM=e 

m,RP=rp; 

BLEMI/BLEME:EM= 

em,RP=rp; 

Blocking/Deblocking of ST 
(SLC must be deactivated) 


C7TDI :ST =C7ST2-x; 

S7TDI:ST=S7ST-x; 

ST Diagnostic 

(SLC must be deactivated) 


Table 3-1. Signaling command comparison 


Note: This overview does NOT replace any official Ericsson 

system documentation. 


User Part 


There are two User Parts, which are used in the PLMN for 
telephony connections, namely: 

• The Telephony User Part (TUP) creates and interprets 
telephony signals for PSTN signaling, MSC to PSTN, 

• The Integrated Services User Part (ISUP), creates and interprets 
telephony signals for ISDN signaling, MSC to MSC, MSC to 
ISDN. 
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Signaling Connection Control Part 

The Signaling Connection Control Part (SCCP) offers other users 
access to the MTP network, for example, the Radio Access 
Network Application Part (RANAP) for communication between 
MSC Server and RNC, the Mobile Application Part (MAP) + the 
Transaction Capability Application Part (TCAP) for 
communication between Switching System nodes, for example, 
VLR to HLR. 

Transaction Capabilities Application Part 

The Transaction Capabilities Application Part interfaces MAP 
messages towards SCCP MAP will be the signal message, while 
TCAP will carry the information from one node to another; it could 
be MSISDN when GMSC asks HLR for a routing address. 


ROUTES 


The definition of a route is 'a group of devices each having the 
same qualities’. By qualities we mean destination, device type, 
signaling system and any other characteristics. 

There are collectively three groups of routes in AXE: 

• Software Routes 

• Internal Routes 

• External Routes 

Routes are defined using the EXROI command. If route 
characteristics require changing, the EXRBC command would be 
used. This is true for all route types. 

The allocation of the devices (remotely or locally hardware) to the 
routes is carried out with the EXDRI command. 

For example: If two PCM systems exist between the same MGW 
node, one-system supports CAS and the other Cl, then by 
definition two routes need to be defined. This is because different 
signaling systems are being used and therefore different device 
types are required. 


LZT 123 9083 R1 A 


© Ericsson 2009 


-47- 





MSC-S R13.1 Blade Cluster Data Transcript 


ERICSSON 


When wanting to find the correct parameters we consult 
Application Information (AI) for the ‘route owning block’ . In this 
case the ‘route owning block’ is the name of the device type. 
Therefore if two different device types are used, two different AIs 
will be required - each containing specific information for that 
particular block. 

SOFTWARE ROUTES 

Software routes are required to allow certain functions to work; 
they point to the function block in the software that will implement 
the function. The main function blocks that require a software route 
to be defined are shown in the next figure. 

Note: Software routes do not require any hardware to be defined. 
For this reason the EXDRI command is not used when defining 
software routes. 


GRI 

GMSC Roaming Interrogation 

GRR 

GMSC Roaming Rerouting 

IA 

Interface Analysis 

MRNR 

Mobile Telephony Roaming Number Routing 

MRR 

Mobile Telephony Roaming Rerouting 

MTB 

Mobile Telephony B-Subscriber Traffic Coordinator 

MIN 

Mobile Telephony Intelligent Network 

MSMO 

MSMT 

IWSMS 

GSMS 

Function Blocks for SMS Handling 


Figure 3-6: Routes Examples of Software Route type 


All of these routes will be defined using commands EXROI and in 
some cases EXRBC will be required (to change default values). 

Note: Some of the routes have a parameter MIS3 that has a 
meaning of either activating or deactivating certain parameters, for 
example, the BO parameter. To find the parameters to be used and 
the use of MIS3 consult AI for the route owning block. 

GRI - GMSC Roaming Interrogation 

The GRI route is required when the GMSC Server needs to consult 
HLR to find a routing address so that the call can be set up. There 
is an MIS3 parameter in this route that activates/ deactivates 
parameters: BO, CO, MIS1 and MIS2. The definition of this route 
will be dealt with in more detail in a later module. Consult AI. 
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GRR - GMSC Roaming Rerouting 

The GRR function coordinates roaming rerouting of a call from a 
MSRN or call forward if the subscriber has the Call Forward 
Unconditional (CFU) supplementary service active. 

IA - Interface Analysis 

The IA function block has an interface to TCS allowing access to 
the A-number and B-number analysis tables. Inputs to IA would be 
the B-number, B-origin (BO) and the A-number. The output is the 
Charging Case (CC), and the A-Charge Origin (ACO). 

MRNR - Mobile Telephony Roaming Number Routing 

The routes defined to the MRNR function block are used for the 
allocation of an MSRN, for a call being set up and for allocating a 
Hand-Over Number (HON), for inter MSC handovers. 

The route name for MSRN would typically be MRNRx while for 
HON it would be HOVERx, where ‘x’ would be a specific number. 
Each route has 100 MSRNs or HONs associated to it. For example, 
if 300 MSRNs are required, three routes are needed: MRNRO, 
MRNR1, MRNR2. 

MRR - Mobile Telephony Roaming Re-routing 

The MRR Function block handles conditional call forwarding in 
MSC/VLR, Call Forward on Busy (CFB), Call Forward on No 
Reply (CFNRY) or Call forward on Not Reachable (CFNRC). The 
MIS3 Parameter is used for this route to activate/deactivate the CO 
and RO parameters. 

MTB - Mobile Telephony B-Subscriber Traffic Coordinator 

This function block is the main coordinating block to set up a call 
to the B-subscriber. The MIS3 Parameter is used to 
activate/deactivate the BO parameter. The BO Parameter is used if 
airtime charging is required. 


MIN 


This function block coordinates the handling of the Messages for 
intelligent network functions. It manages data for routing calls to 
the Intelligent Network (IN). 
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MSMO, MSMT, IWSMS GSMS 

These blocks coordinate the handling of the Short Messages. They 
read data from and load data into the Transaction Capabilities 
Application Part (TCAP) buffer (C7 signaling) and analyze 
received parameters. 

INTERNAL ROUTES 

The following routes require hardware to support the function. In 
each one of the following routes the hardware is allocated only if 
the function has been requested and then on a per call basis. Some 
of the equipment will be allocated for the duration of the call while 
other equipment is used only for the call set up. It is advisable to 
consult AI for the route owning block. 

The following routes shall be defined with EXROI commands (and 
where necessary EXRBC) and the hardware is located in the MGW 
node. 

In Classical MSC/VLR the command EXDRI is needed to 
allocated the corresponded hardware. For MSC-S BC the hardware 
is located in the M-MGW therefore EXDRI is not used. 


CCD 

Conference Call Device 

CSR 

Code Sender and Receiver 

MDTMF 

Mobile Telephony DTMF Sender 

MIWUTH 

Mobile Telephony Interworking Unit 
Device Flandler 

ECDH 

Echo Canceller Device Flandler 

INTRO 

Internal Trunk Route between blades 


Figure 3-7: Routes Examples of Internal Route type 

CCD - Call Conference Device 

The CCD Function block is used to support supplementary 
services: the Multi Party Call (MPTY), the Call Waiting (CAW) 
and the Call Hold (HOLD). 

CSR - Code Sender and Receiver 

The code senders and receivers are required to support the R2 MFC 
signaling. Their use and connection is explained further in this 
chapter. 
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MDTMF - Mobile Telephony DTMF Sender 

The MDTMF block contains functions for operating and 
supervising the Dual Tone Multi-Frequency (DTMF) sending 
Hardware. 

MIWUTH - Mobile Telephony Interworking Unit Traffic Handler 

The block handles Data Transmission Interworking Unit (DTK) 
devices. 

INTRO - Internal Trunk Route 

The function block INTRO acts as an internal trunk for 
interconnecting the blades within the cluster. The block works in 
two different modes (incoming mode and outgoing mode), the 
outgoing INTRO and the incoming INTRO on different blades 
communicate with each other as counterpart. The block uses Open 
Intranode Protocol (OIP) in the interface to TRAM and Internal 
Trunk OIP (INTRO IP) in the interface to the remote blade. 

Echo Canceller Concept 

In a telecommunication network the speech signals can suffer from 
an echo effect. The most common source for echo is the connection 
(hybrid) between the 4- wire transmission network and the 2- wire 
line to a PSTN subscriber. Other causes are long distance 
connections like satellite links and also the speech and channel 
coding used in digital cellular systems. 

This type of echo canceller, the hardware is only connected in 
circuit if it is required. The echo canceller devices are in the MGW 
node. 

Every connection between the digital cellular phone and a PSTN 
phone needs to have the echo effects reduced to achieve an 
acceptable quality of speech. 

Echo cancellers are required for all telephony calls being routed to 
or through networks other than a digital mobile network. Data 
calls, that is, calls using the DTI, do not require echo cancellers to 
be in circuit. 
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Figure 3-8: Echo Cancellers Concept 

Every call requires an Outgoing Echo Canceller (OEC) and an 
Incoming Echo canceller (IEC). MS has a built in echo canceller 
and will automatically insert OEC for a mobile originated call and 
likewise IEC for a mobile terminated call. The network then needs 
to provide the ‘other’ echo canceller. For example, for an outgoing 
call the mobile inserts the OEC and the network needs to provide 
an IEC. 

The parameters are shown in Figure below. 
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ESS Echo Suppressor Subsequent 

0 No IEC available in succeeding exchange. 

1 IEC available in succeeding exchange. 

This parameter is set in the routing case analysis (ANRSI) and gives information whether an IEC can be expected to be available in 
any succeeding exchanges. If not, no request for an IEC connection is sent further and an IEC is connected in own exchange. 

ESR Echo Canceller Required 

0 OEC not required 

1 OEC required in own or preceding exchange. 

2 OEC required in own or succeeding exchange. 

3 OEC required in own or preceding exchange (OEC is always enabled) 

This parameter is set in the routing case analysis (ANRSI) and gives information on whether an OEC is required for a specific 
destination. 

IECREQ Incoming Echo Canceller Requested 

0 No IEC requested 

1 IEC requested 

This parameter is set for incoming routes (EXRBC) from nodes that have no signaling capabilities to transfer requests for echo 
cancellers. IECREQ indicates whether or not the PLMN should connect an IEC for an incoming call on this route. 


Figure 3-9. Echo Canceller Parameters Changed by Command 

The meanings of the parameters shown in Figure above are found 
in the AI for RA and the route owning block. 

Other parameters that are used are shown in Figure below. 


ESI Echo Suppressor/Canceller Information 

0 No EC required. 

1 OEC included, IEC requested. 

2 OEC requested. 

This is a parameter that is derived from the Initial Address Message (IAM) and address 
Complete Message (ACM) sent between exchanges at call setup. It specifies the sending 
exchange's requests for echo cancellers. 

EXSIGN Information on origin of EC information 

0 Backward request for OEC is not possible. 

1 Backward request for OEC is possible. 

2 No backward request. OEC included mobile originated call. 

3 No OEC backward request, BL originated call. 

This is not definable trunk data. This parameter gives information on the possibility of 
requesting an OEC from the preceding exchanges during call setup if it was not provided. 
ECSIGN also gives information whether the call was mobile originated or BL originated. The 
parameter is set by software based on the information received during the call setup process. 

Figure 3-10. Non-Changeable Parameters for Echo Cancellers 


LZT 123 9083 R1 A 


© Ericsson 2009 


- 53 - 







MSC-S R13.1 Blade Cluster Data Transcript 


ERICSSON ^ 


EXTERNAL ROUTES 

External routes point to equipment that leaves the exchange. This 
must be to a PCM system. The PCM system could support CAS 
signaling or C7 signaling. To support the different signaling 
systems, different device types are required. 

Some examples of the devices used for external routes are: 

• BSC - These routes require the MRALT device type (for MSC- 
Server) between MSC-S and BSC. 

• RNC - These routes require the MUIUCM devices type 
between MSC-S and RNC. 

• PSTN/ISDN Networks - These routes require UPDR (MSC- 
Servers). UPD type devices are User Physical Devices and are 
used towards fixed networks. 

• MSC-Servers - There routes require the BID devices type 
between MSC-Servers. 

The remote devices such as MRALT or UPDR and BID will be 
detailed in the following chapters in this book. When local devices 
are used, the optional hardware/subrack is needed. 

The external routes directed towards other exchanges must have 
the correct device type selection, since the signaling system could 
be either C7 or CAS and the device type might require echo 
cancellers or not. Also the device type name can vary from market 
to market. To help selecting the correct device type the reference 
must be made to ER and also to the 1317 list, as the 1317 list is 
application specific. 

DATA TRANSCRIPT 

In the next two sections, examples of data transcript will be given 
for the definition of MTP, the definition of routes to support 
different signaling protocols and the hardware allocation to the 
routes (optional hardware). The definition examples given are only 
for internal routes and external routes. 
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4 x El’s 



MSC-S Blade Cluster 


Figure 3-11: Network Plan 

Figure above shows the information relating to MTP, routes and 
allocation of hardware. The dotted lines represent signaling routes 
only, whereas the solid line denotes a traffic and signaling route. 
Here it will be defined the TDM signaling only as IP signaling 
transport is treated in the next chapter. 

DATA TRANSCRIPT FOR MTP 

The data transcript shown in the network plan and the next figure 
show the commands necessary for implementing MTP (TDM) 
between our node MSC-S BC and other nodes in such as 
PSTN/PLMN (SP=2-3800) and HLR (SP=2-1010). With few 
exceptions MTP part is only necessary to define in SPX. 

Figure below shows the data required when the signaling terminal 
(ST) is of the type C7GST. This ST is implemented by STEB 
board. STEB boards support narrowband and broadband signaling 
transports. STEB is connected in the GEM magazine and via 
backplane to the group switch (XBD boards). 

The information below is from the MSC-S BC point of view: 

• Own Signaling Point Code for SPX1 : 2-3390 

• Own Signaling Point Code for SPX2: 2-3391 

• Own Signaling Point Code for TSC1: 2-3301 
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• Own Signaling Point Code for TSC2: 2-3302 

• Signaling Point Code for HLR: 2-1010, LS=2-1010 

• Signaling Point Code for PSTN/PLMN: 2-3800, LS=2-3800 


!***** DEFINE SIGNALING TERMINAL OF STEB TYPE*****! 
EXRPI : RP=40 , TYPE=RPALI1E; ! STEB Board! 

EXRPI :RP=41, TYPE=RPALI1E; ! STEB Board! 

EXRUI : RP=40&41 , SUID=" 9000/CXC 146 05 R1A03"; 

EXRUI :RP=40&41, SUID = "9000/CXC 146080 R4A03"; 

EXRUI :RP=40&41, SUID=" 9000/CXC 146 03 R1A08"; 

EXRUI :RP=40&41, SUID=" 9000/CXC 146 153 R1A04"; 

EXEMI : EQM=C7GST- 0&&-127, RP=40, EM=0; 

EXEMI : EQM=C7GST- 128&&-255, RP=41, EM=0; 


BLEME : EM=0 , RP=4 0 ; 
BLEME : EM=0 , RP=4 1 ; 


BLRPE : RP=40 ; 

BLRPE : RP=4 1 ; 

NTCOI : SNT=G7 SNT— 0 , SNTP=XM-0-0- 2, SNTV=1, MODE=128; 

NTCOI : SNT=G7 SNT— 1 , SNTP=XM-0-0- 3, SNTV=1, MODE=128; 

EXDUI : DEV=C7GST— 0&&-127; 

EXDUI : DEV=C7GST— 128&&— 255; 

Figure 3-12: STEB Definition DT Required to define the RPs for Signaling 


The data transcript for defining the semi-permanent connection is 
also required. 


I***** C 7 Q WN SIGNALING POINT *****! 

C70PI : OWNSP=2-3390 , SPTYPE=SGW; 

C7PNC : OWNSP=2-3390 , SPID=SPX390; 

i***** c7 SIGNALING POINTS IN OTHER NETWORKS *****! 

C7SPI : SP=2-3800 , OWNSP=2-3390 ; 

C7PNC : SP=2-3800 , SPID=PSTN; 

i***** C 7 SIGNALING TERMINAL IDENTITY *****! 

C7STI : ST=C7GST- 0, ITYPE=16; 

C7STI : ST=C7GST- 1, ITYPE=16; 

C7STI : ST=C7GST-127 , ITYPE=16; 

!***** DEFINITION OF LINK SETS *****! 

C7LDI : LS=2-2556; !PSTN via MGW6 ! 


i ***** SIGNALING LINK DEFINITION ***** ! 

C7SLI : LS=2— 3800 , SLC=0 , ST=C7GST-0 , ACL=A1 , SDL="PSTN-0 , C7GST-0, 
C7SLI : LS=2— 3800 , SLC=1 , ST=C7GST-1 , ACL=A1 , SDL="PSTN-1 , C7GST-1, 
C7SLI : LS=2— 3800 , SLC=2 , ST=C7GST-2 , ACL=A1 , SDL="PSTN-2 , C7GST-2 , 
C7SLI : LS=2-3800 , SLC=3, ST=C7GST-3, ACL=A1 , SDL="PSTN-3 , C7GST-3 , 


UPD1-1" ; 
UPD1-33" ; 
UPD1-65" ; 
UPD1-97" ; 


J***** C 7 MTP ROUTING SEPCIFICATION *****! 

C7RSI : DEST=2-3800 , LS=2— 2556 , PRIO=l ; !Via MGW6 ! 


Note: It should also define it on SPX2 changing OWNSP value. 

Figure 3-13: MTP Definition MSC-S BC (SPX1) to the PSTN 
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! **** SEMI -PERMANENT CONNECTIONS ****! 

EXSPI : NAME=PSTN— 0 ; 

EXSSI : DEV1=UPDR— 1 ; 

EXSSI :DEV2=C7GST— 0; 

EXSPE ; 

EXSPI :NAME=PSTN-1; 

EXSSI :DEVl=UPDR-33; 

EXSSI : DEV2=C7GST— 1 ; 

EXSPE; 

EXSPI : NAME=PSTN-2 ; 

EXSSI :DEVl=UPDR-65; 

EXSSI : DEV2=C7GST— 2 ; 

EXSPE; 

EXSPI : NAME=PSNT-3 ; 

EXSSI :DEVl=UPDR-97; 

EXSSI : DEV2=C7GST— 3 ; 

EXSPE; 

EXSCI : NAME=PSTN-0 , DEV=UPDR-1 ; 

EXSCI : NAME=PSTN— 1 , DEV=UPDR-33 ; 

EXSCI : NAME=PSTN— 2 , DEV=UPDR-65 ; 

EXSCI : NAME=PSTN— 3 , DEV=UPDR-97 ; 

Note: It should also define it on SPX2. 

Figure 3-14: Semi-Permanent Connections MSC-S BC (SPX1) to the 
PSTN 


HIGH SPEED SIGNALING LINK (HSL) 


The feature makes it possible to concentrate the SS7 signaling links 
thus providing high capacity signaling links and leading to better 
cost-efficient network control and flexible network planning. It also 
accommodates the need for increased signaling capacity, mainly 
due to more extensive use of IN and SMS services. In larger 
networks the feature allows flexible network planning, especially 
when using Signaling Transfer Points (STPs). Using HLR 
redundancy will enable more subscribers in an HLR, and thus 
require more signaling capacity between the MSC and the HLR. 

With the HSL there is also a reduction in the signaling delay. 


The O&M of HSL follows the same principles as for conventional 
low-speed links. 


HSL occupies a full 2 Mbit/s (ETSI) or 1,544 Mbit/s (ANSI) link, 
compared with a 64 kbit/s (ETSI) or 56 kbit/s (ANSI) channel. The 
signaling capacity is therefore increased 30 (ETSI) or 24 (ANSI) 
times on the physical layer. 


HSL supports ETSI, ANSI, TTC and Q.703 Annex A signaling. 


The HSL terminal exists in two versions. The STEB based version 
is an enhancement in MSC-S R13. The RPP based version is not 
used in new node deliveries anymore. 
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RPP based 


The RPP based HSL is housed in the GDM-H magazine and it may 
coexist in the same node with the 64 kbit/s (ETSI) or 56 kbit/s 
(ANSI) narrowband signaling terminals. It is implemented on the 
RPP board, one RPP can handle one HSL. The hardware required is 
reduced by 75% compared to conventional signaling terminals. 

The hardware platform used for the HSL C7 application is the 
Regional Processor with the Peripheral Component Interface - 
RPP, and the signaling terminals for HSL are C7STH devices. 
Device 0 will be reserved for hardware supervision and device 16 
will be unused. All 32 STs must be connected to the same EM. 


STEB based 


The STEB is connected to the central processor via either the 
RPB-S or the RPB-E. It is housed in the GEM magazine and it is 
connected to the GS via the DL-34 interface. One board supports a 
maximum of 4 HSL. This maximum number is only usable in 
combination with the RPB-E, otherwise the RPB-S will limit the 
usable bandwidth. All new MSC Server deliveries will use the 
RPB-E, the RPB-S is only supported to allow extension of older 
MSC Server versions. 

The HSLs can be used in various nodes, for example HLR, MSC 
and AUC, where there is a requirement for high amounts of 
signaling. The commands used are the C7 commands already 
discussed. 

However, it is important to notice that the ITYPE parameter is 
given a value of H’ 1 A for HSLs. 

The NUMCH parameter specifies the number of 64 kbps channels 
to be defined. The number can be set from 2 to 30. By specifying 
30, all available channels will be used for signaling (device 1 to 15 
and 17 to 31). 

Figure below gives examples of data transcript for the definition of 
a High Speed Signaling Link (HSL) from MSC-S BC to HLR2. 
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l***** DEFINE SIGNALING TERMINAL OF STEB TYPE*****! 

EXRPI : RP=42 , TYPE=RPALI IE ; ! STEB Board! 

EXRPI : RP=43 , TYPE=RPALI IE ; ! STEB Board! 

EXRUI :RP=42&43, SUID=" 9000/CXC 146 05 R1A03"; ! RPFDR! 
EXRUI : RP=42&43 , SUID=" 9000/CXC 146080 R4A03"; ! RAEXR! 
EXRUI :RP=42&43, SUID=" 9000/CXC 146 03 R1A08"; ! RPIFDR! 
EXRUI :RP=42&43, SUID=" 9000/CXC 146 154 R1A04"; ! C7GSTHR! 

EXEMI : EQM=C7GSTH- 0&&-127, RP=42, EM=0; 

EXEMI : EQM=C7GSTH- 128&&-255, RP=43, EM=0; 


BLEME : EM=0 , RP=42 ; 
BLEME : EM=0 , RP=43; 


BLRPE : RP=42 ; 
BLRPE : RP=43 ; 


NTCOI : SNT=G7SNTH— 0 , SNTP=XM-0-0- 4, SNTV=1, MODE=128; 
NTCOI : SNT=G7SNTH— 1 , SNTP=XM-0-0-15, SNTV=1, MODE=128; 


EXDUI : DEV=C7GSTH- 0&&-127; 
EXDUI : DEV=C7GSTH— 128&&— 255 ; 


Note: it should also define it on SPX2. 


Figure 3-15: High Speed Signaling Link Data MSC-S BC (SPX1) to the 
HLR2 


****** cl SIGNALING TERMINAL IDENTITY *****! 

C7STI : ST=C7GSTH- 0, ITYPE=26; 

C7STI : ST=C7GSTH- 1, ITYPE=26; 

C7STI :ST=C7GSTH-127, ITYPE=26; 

i ***** DEFINITION OF LINK SETS ***** ! 

C7LDI : LS=2-1010 ; !PSTN! 

!***** SIG NALING LINK DEFINITION ***** ! 

C7SLI :LS=2-1010, SLC=0, ST=C7GSTH-1, ACL=A1 , SDL="HLR-0 , C7GSTH-0 , UPDR-257"; 

j ***** ci MTP ROUTING SEPCIFICATION ****** 

C7RSI :DEST=2-1010,LS=2-1010, PRIO=l; ! Direct Link ! 


EXSPI : NAME=HLR-0 , NUM=30 ; 

EXSSI : DEVl=UPDR-257 ; 

EXSSI : DEV2=C7GSTH— 1 ; 

EXSPE ; 

EXSCI : NAME=HLR-0 , DEV=UPDR-257 ; 


Note: It should also define it on SPX2. 

Figure 3-16: HSL Semi-Permanent MSC-S BC (SPX1) to the HLR2 


DATA TRANSCRIPT FOR THE DEFINITION OF ROUTES AND 
ALLOCATION OF HARDWARE 

Routes Supporting ISUP Protocols 

From figure below it can be seen that the connections from MSC-S 
BC to PSTN/ uses the ISUP protocol. The device type used is 
UPDR (ET1551 board). This device type supports the ISUP 
signaling protocol and does not have echo cancellers. Note that the 
UPDR devices are related to the Remote devices placed in the 
MGW nodes. 
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In the examples shown in figure below, all routes, whether for 
speech or signaling, are both-way routes. In this situation both the 
outgoing and incoming routes are defined together; the first named 
route will always be taken as the outgoing route name. 

The Function Code (FNC) tells the system what type of route is 
being defined. If FNC=3, the routes are defined for speech, and if 
FNC=7, the routes are defined for signaling. Remember that these 
values are only applicable for the UPDR device type. 

Note: The parameters assigned in the next figure are only example 
values and should not be assumed to be standard when defining 
routes of this type. The ISUP route is handle by the TSC Blades 
only. 


! **** ROUTES TOWARDS PSTN ****! 

EXROI : R=PSTN10&PSNT1I , DETY=UPDR, FNC=3, SI=ISUP4, SP=2-3800; 
EXRBC : R=PSTN10, TTRANS=1; 

EXRBC : R=PSTN1I , BO=l, CO=31, PRI=10; 

EXROI : R=PSTN1S0&PSNT1SI , DETY=UPDR, FNC=7; 

EXRBC : R=PSTN1SI , PRI=10; 


I**** ROUTES TOWARDS MSC1 

EXDRI : R=PSTN10&PSTN1I , DEV= 
EXDRI : R=PSTN10&PSTN1I , DEV= 
EXDRI : R=PSTN10&PSTN1I , DEV= 
EXDRI : R=PSTN10&PSTN1I , DEV= 
EXDRI : R=PSTN10&PSTN1I , DEV= 
EXDRI : R=PSTN10&PSTN1I , DEV= 
EXDRI : R=PSTN10&PSTN1I , DEV= 
EXDRI : R=PSTN10&PSTN1I , DEV= 


HARDWARE ALLOCATION ****! 

UPDR— 2 & & — 3 1 , MISC1=2 , MISC2=0 ; 
UPDR-34&&-63 , MISC1=34 , MISC2=0 ; 
UPDR-66&&-95 , MISC1=66, MISC2=0 ; 
UPDR-98&&-127 , MISC1=98 , MISC2=0 ; 
UPDR-129&&-159, MISC1=129, MISC2= 
UPDR— 161&&— 191 , MISC1=161 , MISC2= 
UPDR-193&&-223 , MISC1=193 , MISC2= 
UPDR-225&&-255 , MISC1=225 , MISC2= 


! PCM 1 SIG.T/S 1! 
! PCM 2 SIG.T/S 1! 
! PCM 3 SIG.T/S 1! 
! PCM 4 SIG.T/S 1! 
■0; ! PCM 5 NO SIG! 

0; ! PCM 6 NO SIG! 

0; ! PCM 7 NO SIG! 

0 ; ! PCM 8 NO SIG! 


EXDRI : R=PSTN1S0&PSTN1SI , DEV=UPDR-l&-33&-65&-97 ; ! SIGNALING ROUTES ! 

Figure 3-17: ISUP Routes Definition MSC-S BC (TSC Blades) to the 
PSTN 


When the speech routes are defined, the SI and SP parameters must 
be used. The SP parameter depends on the destination of the 
Message Transfer Part (MTP), while the SI parameter is defined as 
the Permanent Exchange Adaptation and will be found in the 
Parameter List for the UPLTD function block of the E-module. 


Two both-way routes, one for speech and the other for signaling, 
have been defined towards PSTN. 


The network diagram plan shows that eight PCM systems 
required to be connected to the route, connecting MSC-S BC 


PSTN. 


are 

and 
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The time slot 1 is reserved/used for signaling, from the first four 
PCM systems shall be allocated to the signaling route and that time 
slot 2 to 31 shall be allocated to the speech route. The PCM 
systems 5 to 8 do not have any time slots allocated to the signaling 
route yet. Therefore, all 31 time slots will be allocated to the 
speech routes, making 244 speech circuits in total. 

Remember that the timeslots are in fact physically connected in the 
M-MGW node. 

SLS is to be used when sending ISUP messages between the two 
nodes. It ought to be noted that on this route, time slot 1 in each of 
the first four PCM systems is used for signaling, four SLCs. 

The last EXDRI command allocates the devices of the first four 
PCM systems to the signaling routes. 

Routes Supporting MAP Signaling Protocols 

From the network diagram it can be seen that only one signaling 
route is required to support MAP signaling between MSC-S BC 
and HLR2. In a real network MAP signaling is used to other nodes 
like EIR or MSC. A specific signaling route is required here since 
no other route is available that could carry the MAP message. 

Figure below shows the data transcript required for defining the 
signaling route and the allocation of hardware towards HLR2, 
which use the High Speed Signaling link (HSL). Make sure that all 
the circuits are connected to the routes except 0 and 16. 

!**** ROUTES TOWARDS STAND-ALONE HLR ****! 

EXROI : R=HLR2SO&HLR2SI , DETY=UPDR, FNC=7 ; 

!**** h/W ALLOC. FOR ROUTES TOWARDS S.A HLR ****! 

EXDRI: R=HLR2SO&HLR2SI , DEV=UPDR-257&&-271&-273&&-287; 

Figure 3-18: DT for Routes Supporting MAP MSC-S BC (TSC Blades) to 
the HLR2 
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4 Signaling over IP in MSC-S BC 


Objectives 


Setup MSC-S BC based on a network scenario and 
system documentation. 

■ Check the defined IP stack on CP. 

■ Define the signaling transport (SIGTRAN) in an MSC-S blade. 

■ Set SUA signaling between MSC-S blades. 

■ Write the exchange data for traffic connections to other MSC- 
S Blades and other networks by interpreting the Exchange 
Requirements. 

■ Create exchange data for the signaling connections towards 
HLR and other MSC-S Blades and towards other networks by 
interpreting the Exchange Requirements. 





Figure 4- 1 . Objectives 
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OVERVIEW 


An APZ based node can be configured to support signaling 
transport over IP network. 

In Non-BC system, for example, like APZ 212 40/50, two types of 
IP stack for APT signaling are supported: 

• IP stack on RP (GARP). 

• IP stack on CP. 

In the MSC-S Blade Cluster system, it includes two APZ systems, 
Single Sided CP (MSC and TSC Blades) and Dual Sided CP. SPX 
uses Dual sided CP and blade uses Single Sided CP. IP stack is 
supported on both SPX and blades. 

The main idea here is to show the data transcript of the internal 
signaling and also the signaling to external nodes. 

Signaling in the MSC-S BC uses the feature IP on CP, which is also 
used by the classical MSC-S. In the MSC-S BC, all the SIGTRAN 
protocols are supported in the IP stack on CP. 

The SIGTRAN feature makes it possible to transport Signaling 
System No.7 (SS7) signaling traffic (MAP, CAP, INAP, ISUP, 
BICC, BSSAP and RANAP), and GCP signaling over an IP bearer. 
The solution is based on the IETF Stream Control Transmission 
Protocol (SCTP) and the MTP3 User Adaptation Layer (M3UA). 
With this feature the MSC owns IPv4 interfaces. Thus the MSC can 
be connected to a pure IPv4 network. 

Included in the SIGTRAN feature are also the O&M actions, 
functions and tasks needed to handle the IP data and addressing, 
the SCTP Layer and the MTP3 User Adaptation Layer. 

OVERALL ARCHITECTURE 

This section contains the IP on CP overall structure for MSC-S BC 
node. The Non-BC node will not be mention any more. 

Figure below illustrates the overall structure for APZ based BC 
node - MSC-S BC. 
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Figure 4-2. IP on CP feature 

The BC node uses the IS approach to make use of the already 
existing network structure on the site. 

The IP stack on CP exists in both SPX and blade. TCP, UDP and 
SCTP are supported. 

A pair of ISER is acting as a L3X to provide LAN connectivity to 
outside IP network. APG and SIS are part of the system for 
connection to OSS. One of APG acts as single point of entry for all 
MML commands towards SPX and blade. IP stack is configurable 
through one of the APG. Statistics and charging are also handled 
through APG 10 system. SIS is mainly for the O&M of the IS 
infrastructure. 

All the traffic is tagged except that APG traffic is untagged 
Ethernet traffic. 

Virtual Interfaces and IP Addresses 

A Virtual Interface (VIF) is a logical representation of an interface 
that is used to send data to or receive data from the connected 
network. The VIF is connected to a VLAN and all data passing 
through a VIF belong to the connected VLAN. 

IP addresses, routing tables can only be configured on VIFs. 
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Based on the hardware different types of VIFs are supported: 

• Single Sided CP : The single sided CP (Blades) supports two 
physical Ethernet interfaces. These interfaces will appear to the 
IP stack as a single interface (LAG) because of the Ethernet 
link aggregation. Virtual interfaces can be configured on top of 
this single interface A virtual interface defined on a single 
sided CP is called a ‘named VIF’ (nVIF). The VLAN name 
used for nVIF has to be defined as part of the Integrated Site 
environment (IS) before. 

• Dual Sided CP : The dual side CP (SPX nodes) supports two 
physical Ethernet interfaces (ETHA, ETHB). Virtual interfaces 
can be configured on top of each of the interfaces. 

For a dual sided CP the virtual interface name includes the physical 
interface name (ETHA or ETHB) it is connected to and a number 
representing the VLAN to be used for this virtual interface, for 
example: 

ETHA- 10 is connected to ETHA and uses VLAN 10. 

In case two virtual interfaces are defined on the two Ethernet 
interfaces, and the two virtual interfaces belong to the same VLAN 
(adjacent interfaces) then the interfaces are called ‘virtual interface 
pair’ or VIF-pair. 

Specific functions can only be applied on a virtual interface pair, 
for example the ‘Router Supervision’ function or the TP Address 
Migration’ function. 

A virtual interface is always connected to one Ethernet interface 
(Dual Sided CP) or to the interface of the Ethernet link aggregation 
(Single Sided CP). On a virtual interface an operator can define 
Application IP addresses. 

Application IP addresses belong to one or more defined IP subnets. 
A VLAN comprehends one or more IP subnets. For the IP stack on 
CP, a specific subnet belongs to exact one VLAN. 

Router supervision function is available only for a dual sided CP. 
Each VLAN can have one router supervision instance. Each router 
supervision instance has 2 router supervision IP addresses, which 
are used to supervise the IP connectivity between the interface and 
the supervised gateway in absence of any other IP addresses on the 
VIF. Router supervision IP addresses and Gateway IP addresses can 
be defined as part of Router Supervision configuration. 
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All the IP addresses and VLANs are defined in the startup process 
and from DT point of view these information are used as given 
data. 

SIGNALING IN THE MSC-S BC 

In figure below shows the main signaling transport used internally 
and externally in the MSC-S Blade Cluster. Note that internally 
there is a new protocol over SCTP/IP, the SUA - SCCP User 
Adaptation layer. SUA is used between MSC and TSC Blades and 
also between Blades and SPX nodes substituting the SCCP. New 
parameters and concepts appear here and they will be explained 
further. 





SUA 


SCTP 


IP 


TDM Optional 
Traffic 



SCCP 

MTP3 


MTP2 


MTP1 


ATM Optional 
Based 
Traffic 


SCCP 


MTP3B 


SAAL 


ATM 


SCCP 


M3UA 


SCTP 


IP 


Figure 4-3. SIGTRAN in MSC-S 

TDM and ATM signaling transports are also supported in the MSC 
BC but there required optional hardware as described before. 


All the SS7 protocols such as MAP, CAP, INAP, ISUP and others, 
use SIGTRAN as signaling transport. Note that now, the 
SIGTRAN protocol stack can vary from M3UA/SCTP/IP and 
SUA/SCTP/IP. Internally, SCCP protocol is substituted by SUA 
protocol. 
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Concepts 


The concept supported by this function is IETF SUA concept. The 
following explain the concepts and used definitions in more details. 

This section describes the concept that follows RFC3868 standard. 

Application Server (AS): Application Server is a logical entity 
serving a specified Routing Key in SUA network. The AS contains 
a set of one or more unique Application Server Processes, of which 
one or more is processing traffic. Application Server is SCCP User 
Application which uses SUA and underlying SCTP/IP network as a 
transport network. 

Signalling Gateway (SG): Signalling Gateway is a network 
element that terminates switched circuit networks and transports 
SCCP-User signalling over IP to an IP signaling endpoint. A 
Signalling Gateway could be modelled as one or more Signaling 
Gateway Process, which is located at the border of the SS7 and IP 
networks. 

Signalling Process (SP): Signalling Process is the process instance 
that uses SUA protocol to communicate with other signalling 
processes in SUA network. Each Signaling Process owns an SCTP 
endpoint, which is used for receiving and sending SUA messages. 

In SUA network, Signalling Process can be either Application 
Server Process (ASP) or Signalling Gateway Process (SGP). 

Application Server Process (ASP): Application Server Process is 
an element of a distributed IP based signalling node. It is 
provisioned to receive certain ranges of signalling traffic, that is, 
serve particular ASes. 

Signalling Gateway Process (SGP): Signalling Gateway Process 
is a process instance of a Signalling Gateway. 

The function of the SUA Signalling Gateway Process comprises 
the SCCP layer functions and underlying SS7 stack, and SUA layer 
functions and underlying SCTP/IP stack. 

Routing Key (RK): describes a set of SS7 parameters and/or 
parameter ranges that uniquely defines the range of signalling 
traffic configured to be handled by a particular Application Server. 
Routing Keys are mutually exclusive in the sense that one 
signalling message cannot match more than one Routing Key 
within a SUA node, i.e. within an SG or a Signalling Process. 
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Routing Context (RC): is a value that uniquely identifies a 
Routing Key at Signalling Gateway Process. 

SCTP association: SCTP association is a protocol relationship 
between SCTP end points. The SCTP transport addresses used by 
the end points in the association uniquely identify an association. 
Two SCTP end points must not have more than one SCTP 
association between them at any given time. 

SCTP endpoint: SCTP endpoints are the communicating instances 
in SCTP. A set of IP addresses and a port number define an SCTP 
endpoint. The port number is used by SCTP to access the user 
application of the above layer. 

Client - server mode: Client-Server mode applies to SCTP 
Association establishment / teardown. The node is defined as 
server in client-server configuration if it receives requests to 
establish an SCTP association from the client node. Client is the 
initiator of SCTP association establishment or teardown requests. 

Any signalling process may act as a client or server; however it is 
recommended that ASP is the client and SGP is the server by 
default. 

Socket API: The Socket Application Programming Interface 
provides a standard design interface across diverse operating 
systems and multiple platforms. 

SUA uses IP stack on the CP, avoiding the need for the GARP 
boards but allowing the coexistence of both IP stacks within one 
node. 

Stream: A stream is unidirectional logical channel established 
from one to another associated SCTP End Point, within which all 
user messages are delivered in sequence, except for those 
submitted to the unordered delivery service. 

Hosted Point Code (HPC): HPC is a new type of SPC in MTP 
network representing Remote Signaling Point residing in SUA 
network. In other words, it is a destination that exists in SUA 
network and it is accessible from external network through the 
local Signalling Gateways (SGs). 
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SS7 O VER IP CAPABILITY IN ALL AXE AND CPP NODES 

All AXE and CPP nodes are capable of handling SS7 over IP 

In the AXE based nodes, like the MSC/VLR, MSC/MGW, MSC 
Server, TSC, TSC Server, this is achieved by adding an IP 
Signaling Terminal HW (SCTP-ST) to the node. The solution is 
flexible, it allows the operator to add HW to support SS7 over IP 
gradually as the signaling traffic is moved to IP transport. The 
upgrade can be done without disturbing the ongoing signaling 
traffic. 

To make the SS7 over IP network complete, other nodes that are 
vital in the signaling network, like the HLR, AUC, FNR and STP 
could be upgraded in the same way to enable a complete signaling 
network to use SS7 over IP. All nodes are capable of having SS7 
over IP simultaneously with SS7 over TDM, which means that the 
migration could be done one step at the time. 

The M-MGW is SW upgraded to support SS7 over IP over the 
existing Ethernet interfaces. 



Figure 4-4: MTP Signaling Over IP Protocol View 


Shown in the Figure 4-3 is a logical diagram of IP base signaling 
network with nodes and protocol stack used for signaling over IP. 
There are some new concepts introduced. 
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SCTP 


SCTP (IETF RFC2960) provides a reliable, connection-oriented 
bearer service. The connection between two nodes is called an 
SCTP association and can consist of multiple paths through an IP 
network. Multiple paths are based on the multi-homing feature, 
which allows each SCTP end point to use multiple IP addresses for 
each association. One of the paths is used as the primary 
communication channel. If the primary path becomes unavailable, 
one of the other available paths is used. Availability of paths is 
monitored using a heartbeat mechanism. An association can 
support multiple streams. A stream can be seen as an independent 
communication channel in the sense that a retransmission on one 
stream doesn’t stop or slow down the traffic in another stream. 
Within a stream, the order of transmitted messages can be 
guaranteed. 


M3UA 


The MTP3 User Adaptation Fayer (M3UA) function defines a 
protocol for supporting the transport of any SS7 MTP3 user 
signaling (for example, ISUP and SCCP messages) over IP using 
the Stream Control Transmission Protocol (SCTP) services. It also 
may provide gateway functionality that enables seamless operation 
of MTP3 user peers in the SS7 and IP domains. 

There are two kinds of nodes which use M3UA to be considered: 
IP Signaling End Points (IPSEPs) and Signaling Gateways 
(SGWs). 

A node which is configured to be an IPSEP is able to handle 
originating and terminating traffic in the IP network as well as in 
the SS7 network. An IPSEP includes all functionality that is 
available within an SEP 

A node which is configured to be an SGW is able to handle 
originating and terminating traffic in the IP and SS7 networks, as 
well as transfer (SS7 <-> SS7) and gateway (SS7 <-> IP) traffic at 
M3UA level. The specific functionality available within an SGW is 
described in reference. 

M3UA consists of the following functions: 

• M3UA Signaling Message Handling. 
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This function handles the routing of signaling messages to IP 
through the suitable SCTP association and stream, and the 
distribution of received messages from IP within the local 
exchange. 

• M3UA Routing 

This is used at each SP to determine the outgoing SCTP association 
and stream through which a message is to be sent towards its 
destination through IP 

• M3UA Discrimination 

This is used at each SP to determine whether or not a message 
received from IP is destined to the SP itself. In the IPSEP nodes the 
messages not destined to the OWNSP are discarded. 

• M3UA Distribution 

This is used at each SP to deliver the messages received from IP 
(destined to the SP itself) to the appropriate MTP3 user or to the 
Signaling Network Management part of M3UA. 

Two types of traffic are handled in an IPSEP: 

Incoming 

When a message is received from an SCTP association in an 
IPSEP it is decided whether it is to be terminated or to be 
discarded. If the message is to be terminated and is a Transfer 
(DATA) message, it is distributed to the indicated MTP3 user. If the 
message is a Management (MGMT), SS7 Network Management 
(SSNM), ASP State Management (ASPSM) or ASP Traffic 
Maintenance (ASPTM) message, it is distributed within the 
M3UA. 

Outgoing 

When a message is sent from an MTP3 user through IP, the SCTP 
association and outbound stream predetermined to transfer the 
message to the indicated destination are selected. The message is 
then sent on this SCTP association and stream. 

• M3UA Signaling Network Management. 
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It is divided into three sub-functions as follows: 

- M3UA Signaling Traffic Management is in charge of 
diverting traffic to alternative IP signaling routes in case of IP 
signaling route failure and of controlling traffic when 
congestion occurs at a signaling point in the IP network. It is 
also in charge of restarting a signaling point and of slowing 
down traffic when congestion occurs towards a signaling 
point. 

- M3UA Signaling Route Management distributes 
information about the IP signaling network status. 

- M3UA Association Management defines, establishes and 
activates idle SCTP associations, and deactivates and 
terminates SCTP associations. 


TRAFFIC CASES 


Here give an example of transfer traffic shown in Figure 4-4. 
Transfer traffic from IP network consists of messages received 
from the IP network which is designated for a destination signaling 
point other than the own signaling point. Transfer traffic is received 
and discriminated from terminating traffic, thus, if the destination 
of a message is not the own signaling point, the message does not 
terminate at this node and it should be transferred towards the 
appropriate destination. 

The next step will be to check whether the own IP signaling node is 
an IPSEP or a SGW: 

• IPSEP 

If the own IP signaling node is an IPSEP the transfer traffic will not 
be processed (only terminating traffic is handled in an IPSEP). 

. SGW 

However, if the own IP signaling node is a SGW (terminating and 
transfer traffic are handled in a SGW), the message has to be routed 
towards the appropriate destination. 

The SGW will then make the protocol transfer from IP to other 
protocols used by connected network (e.g. C7/ATM or STM). 
Shown as Figure below. 
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NETWORK CONFIGURATION EXAMPLE 

Considering the scenarios where external SS7 SEPs have access to 
SUA Application Servers via single or multiple SUA SGs, two 
network configurations are supported. 

As MSC-S BC there are always two SPX nodes acting as SGs, so 
only the Multiple SG Configuration is shown: 

Multiple SG Configuration 

External SS7 nodes using the Multiple SG configuration mode sees 
ASPs as one SS7 node connected to them via two STPs. In this 
case the SUA SGs act as MTP3 STPs towards the external nodes. 



MSC Blade 


MSC Blade 


() Association ) 


Figure 4-6. Multiple SG Configuration example 
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Each ASP (represents the MSC Blades) is connected over 
predefined transport (one association) with specific SGP 
(represents the SPX node). 

The SG contains only one SGP Each SGP manages specific AS 
over one or number of defined. 

In the figure above the ASP represents the MSC Blades (we do not 
define SUA signaling for TSC Blades), the SGP represents the SPX 
nodes and NE any node in the SS7 network, such as HLR, BSC, 
RNC, SMS-C and so on. 

SIGTRAN definition between MSC Blades and SPX nodes are 
done using the VLAN 1001, as stated before. The IP addresses used 
so is the ones configured in the VLAN 1001 which is possible to 
check by sending the command IHIFP in each node and blades. 

Internal signaling transport is done in the startup or implementation 
phase. 

Assuming that all the physical IP backbone and SIGTRAN are 
already done, SUA part should be defined as follow: 

Configuration in SGP 

SGP configuration described in this chapter is valid for AS defined 
in Multiple SG configuration. 
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Configuration of MTP Layer 

Own SPC Definition 

Each node in SS7 network is identified by means of an SPC. 

C70PI : OWNSP = 2 - 091 , SPTYPE = SGW; 

C70PI : OWNSP=2 -092, SPTYPE=SGW; 

Own SPC is defined by means of C70PI command for ITU, MPT 
and TTC networks and S70PI for ANSI networks. 

HPC Definition 

The HPC is a new type of SPC in MTP network. The HPC 
definition is only possible if SPXFUNCTION feature is available. 

DBTRI ; 

DBTSC : TAB = AXE PARS , SETNAME=S IGI PS , 

NAME = SPXFUNCTION, VALUE=1; 

DBTRE : COM ; 

The HPC definition is mandatory for any SGP configuration valid 
for AS defined in Multiple SG configuration. 

HPC is defined by means of C7HPI command for ITU, MPT and 
TTC networks and S7HPI for ANSI networks. For MSC-S BC 
R13.1 only ITU-T standard is supported. 

For the example case the point codes 2-091 on SPX1 and 2-092 on 
SPX2 are defined as SGW. Furthermore the common MSC Point 
Code 2-099 must be defined as HPC. From the HER point of view 
it sees the MSC-S BC as single point code, i.e. the SP=2-099: 

C7HPI : HPC=2 -099; 

Destination SPC Definition 

Definition of destination SPCs for ITU, MPT and TTC networks is 
performed using the command C7SPI. 

Now, the SPX should knows the HER signaling point code: 

C7SPI : SP=2 -100; 

C7PNC :SP=2-100, SPID=HLR100; 
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Configuration of SCCP Layer 


For configuration of SCCP layer on SG the existing SCCP 
commands must be used. Here, only the specific SCCP/SUA 
configuration differences comparing to existing SCCP command is 
highlighted. 

Although the configuration of SCCP layer is independent from 
configuration of SUA layer, prerequisite for configuration of SCCP 
layer is configuration of MTP layer. 

Considering the scenarios where external SS7 SEPs have access to 
SUA Application Servers via Multiple SG, the remote SCCP 
Network Signalling Point (representing the external SS7 elements 
from the SG perspective) must be defined by means of command 
C7NPI and C7NPC for ITU, MPT and TTC networks and S7NPI 
and S7NPC for ANSI networks. In Multiple SG scenario HPCCON 
parameter must be set. Note that when HPCCON parameter is set 
on SGP, it is not possible to define any SSN. 

In order to indicate to the SCCP layer that the remote peer operates 
to the MSC Server Blade Cluster via Multiple SGs (two SPXes, 
Multiple SG scenario) the following must be defined: 

C7NPI :SP=2- 100, HPCCON; 

In the SPX nodes, this is the destination signaling point that will 
the converted from SUA to SCCP protocol. 

■ Own SPC Definition: 

C7OPI:OWNSP=2-091, SPTYPE=SGW; !SPX1 ! 

C70PI :OWNSP=2-092, SPTYPE=SGW; !SPX2! 

■ Hosted Signaling Point: 

C7HPI:HPC=2-099; !HLR sees HPC as a unique point code from 
MSC-S BC! 

■ Destination Point Code: HLR node. 

C7SPI:SP=2-100; 

C7PNC:SP=2-1 00, SPID=HLR100; 

■ Destination Point Code (HLR) in the SCCP level: 

C7NPI:SP=2-1 00, HPCCON; 

Figure 4-8: SS7 Signaling Definition SPX Nodes 
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Configuration of SCTP Layer 

This section describes only the mandatory steps in SCTP layer 
configuration which must be done as prerequisites to SUA layer 
configuration. 

Note that SUA is user of new Socket API based SCTP 

SCTP End point Initialization 

SUA layer binds as a user to the SCTP layer, creating a new SCTP 
end point by means of command IHBII. 

The parameters provided by the command are an SCTP end point 
identity, up to four local IP addresses, a local port number as an 
optional parameter, and indication that the traffic will be distributed 
to SCTP on CP 

Prerequisite for command IHBII is to have local IP address (es) 
defined on IP level. 

The same local IP address set can be used by various SCTP end 
points as long as different local SCTP port numbers are provided in 
the command. If not provided, value 14001, representing the port 
number allocated for SUA (well known port), for the local port 
number is used. 

The SERVER mode should be used for associations towards SUA 
nodes defined as pure clients for achieving better interoperability. 

Follow the commands sent in the SPX nodes: 

IHBII : LIP= " 192. 168. 1. 201 192. 168. 1.202", 
EPID=SUASEP01 , USER=SUA, MODE= SERVER, 
SCTPCP ; 

SCTPCP parameter indicates that is defining the EPID for IP on 
CP. User parameter indicates the protocol that will use the EPID. 

SCTP Association Data Definition 

Once an SCTP End Point is created, one or several SCTP 
Associations can be defined. Command IHADI is used for that 
purpose. 

The mandatory parameters provided by the command are an SCTP 
association identity, an SCTP end point and up to four remote IP 
addresses. 
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The optional parameters are a remote port number and a number of 
outbound streams for outgoing traffic through the association. 

When an SCTP association is defined in SERVER mode, only the 
IP address of the remote must be provided in the command, 
omitting the remote port number. The remote client typically uses 
use ephemeral ports, so that the remote port number is not known. 

The first given remote IP address in the command will be the first 
IP address to which association establishment is initiated. 

I HAD I : SAID=SPXSUA1 , EPID=SUASEP01 , 

RIP="192 . 168 . 1 . 103" , SCTPCP ; 

• SCTP End point Initialization 

IHBII:LIP= “192.168.1.201” & “192.168.1.202”, EPID=SUASEP01 , 
USEFUSUA, MODE= SERVER, SCTPCP; 

■ SCTP Association Data Definition 

IHADI:SAID=SPX1SUA, EPID=SUASEP01 , RIP=“1 92.168.1. 103”, 
SCTPCP; 

Figure 4-9: Signaling Transport SPX Nodes 


Configuration of SUA layer is valid for ITU, MPT, TTC and ANSI 
networks. 

AS Definition: 

Application Server is uniquely identified by Routing Key. The AS 
must be defined for specific local Signaling Process behaviour. 

Application Server is defined by means of command UAASI and 
UAASC. 

Some of parameters in UAASI command are: AS local identifier 
(ASID) , protocol type (PROT), Signaling Process type (SPTYPE), 
Destination Point Code (DPC) related to Routing Key uniquely 
applied to AS being defined, Network Indicator (NI) and Routing 
Context (RC). 

All parameters are valid for ITU, MPT, TTC and ANSI networks 
except NI which is not valid for ANSI network. 

Each DPC defined within AS defined in Multiple SG configuration 
has to be defined first on MTP level as HPC. 


Configuration of SUA Layer 
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The RC is mandatory data in UAASI command. This is because 
looking from SGP AS must have unique RC value. 

The SINGLESG parameter must not be used in any AS defined for 
SGP. 

On each SPX the following AS shall be defined for the example 
case. 

UAASI : AS ID=AS2 099, SPTYPE=SGP, DPC=99, NI=2, 

PROT=SUA, RC=2 0 9 9 ; 

Please note that it is possible to define more then one DPC to an 
Application server (UAASC). 

Definition of SSN related to AS: 

This step is omitted for AS defined in Multiple SG configuration. 

Remote Signaling Process Definition: 

Remote Signaling Process represents remote SUA peer to which 
local process will be connected for specific AS. Remote Signaling 
Process is defined by means of command UASPI. 

The parameters in command are: Signaling Process identifier 
(SPID), protocol type (PROT), Signaling Process type (SPTYPE) 
and optionally SCTP association (SAID) used for transport 
connection to that remote Signaling Process. 

Note that meaning of Signaling Process type parameter in UASPI 
command has opposite meaning than in UAASI command, because 
in UAASI command, SPTYPE describes local behavior of defined 
AS. 

As described above, SAID parameter is optional in command 
UASPI. This is in order to be able to configure SUA application, 
independently of configured transport. Transport can be applied in 
the end, using command UASPC. Only one SAID can be applied 
for specified SP. Application Server Processes has to be established 
on each SPX to each MSC blade: 

UASPI : SPID=BLD2 , SPTYPE=ASP, PROT=SUA; 

UASPI : SPID=BLD3 , SPTYPE=ASP, PROT=SUA; 


UASPI :SPID=BLD17, SPTYPE=ASP, PROT=SUA; 
UASPC :SPID=BLD2, PROT=SUA, SAID=SUAMSC1 ; 
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UASPC : SPID=BLD3 , PROT=SUA, SAID=SUAMSC2 ; 


UASPC : SPID=BLD17 , PROT=SUA, SAID=SUAMSC1 5 ; 

Signaling Process Relation Definition: 

Once AS with its Routing Key and remote Signaling Process are 
defined, the remote Signaling Process relation with AS must be 
initiated. The type of AS and the type of remote Signaling Process 
must be forming a valid pair (SGP-ASP). 

One remote Signaling Process can be assigned to more than one 


The remote Signaling Process relation with AS is initiated by 
means of command UAPRI. 

The parameters in command are: Signaling Process identifier, 
protocol type, AS local identifier, and optionally Routing Context. 
Routing Context is assigned for local ASP types only. For local 
SGP, Routing Context as a unique identifier is defined in command 
UAASI. 

UAPRI :SPID=BLD2, AS ID=AS2 099, PROT=SUA; 

UAPRI : SPID=BLD3 , ASID=AS2 0 9 9 , PROT=SUA; 


UAPRI : SPID=BLD17 , ASID=AS2 0 9 9 , PROT=SUA; 

• AS Definition: 

UAASI :ASID=AS2099, SPTYPE=SGP, DPC=99, Nl=2, PROT=SUA, 
RC=2099; 

• Remote Signaling Process Definition: 

UASPI:SPID=BLD2, SPTYPE=ASP, PROT=SUA; 

UASPI:SPID=BLD17, SPTYPE=ASP, PROT=SUA; 
UASPC:SPID=BLD2, PROT=SUA, SAID=SUAMSC1 ; 
UASPC:SPID=BLD17,PROT=SUA,SAID=SUAMSC15; 

■ Signaling Process Relation Definition: 

UAPRI:SPID=BLD2,ASID=AS2099,PROT=SUA; 

UAPRI:SPID=BLD17,ASID=AS2099,PROT=SUA; 

Figure 4- 1 0: SUA Definition SPX Nodes 


AS. 
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Configuration in ASP 

This section describes SUA configuration in ASP, i.e. in the MSC 
Blades. TSC Blades use SUA as well but it is not defined by the 
operator. 

Configuration of SUA in ASP is valid for ITU, MPT, TTC and 
ANSI networks. 



The following tasks must be performed to configure SUA layer: 

AS definition: 

The RC must not be used in UAASI command. 

SINGLESG parameter must not be used for AS defined in Multiple 
SG. 

On each MSC blade the following AS shall be defined for the 
example case. 

UAASI : AS ID=AS2 099, SPTYPE=ASP, DPC=99, NI=2, 

PROT=SUA ; 

SPC Definition for Remote Destination in SUA Network: 

A remote destination which can only be reachable via SUA 
network must be defined in ASP. 
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A definition of SUA NE SPC for ITU, MPT and TTC and ANSI 
SUA networks is performed using the command UANPI. This is 
how the MSC Blades know the “destination signaling point” in 
SUA network. 

The parameters in command are: Signaling Point and Application 
Server Signaling Point. Both parameters are mandatory since they 
form a valid [Remote DPC, OPC] pair. 

For the example case following remote destination is defined on 
each MSC blade: 

UANPI :SP=2- 100, ASSP=2-099; 

Note that specific remote destination in SUA network is allowed to 
be defined over one Application Server in specific ASP. The same 
remote destination in SUA network over another Application 
Server in the same ASP is not allowed to be defined. The same 
remote destination in SUA network can be only defined in other 
ASP over the same or different Application Server. 

Definition of Network Subsystem (SSN) Related to Remote 
Destination in SUA: 

For example, the following shall be defined on all MSC blades. 


UANSI : SP=2-100, SSN=6 ; 

Global Title Translation Tables Definition: 

The definition of GTT tables in ASP (it is optional) is still done by 
existing SCCP commands. No differences in configuration 
considering the specific SUA configuration exist. 

For more details on Global Title Translation tables handling (GTT) 
see the relevant SCCP OPI documents. 

Remote Signaling Process Definition: 

Remote Signaling Process represents remote SUA peer to which 
local process will be connected for specific AS. Remote Signaling 
Process is defined by means of command UASPI. 

The command UASPI is mandatory in ASP. 

The parameters in command are: Signaling Process identifier, 
protocol type, Signaling Process type, Signaling Gateway identifier 
and optionally SCTP association used for transport connection to 
that remote Signaling Process. 
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Note that meaning of Signaling Process type parameter in UASPI 
command has opposite meaning than in UAASI command, because 
in UAASI command, SPTYPE describes local behaviour of 
defined AS. 

As described above, SAID parameter is optional in command 
UASPI. This is in order to be able to configure SUA application, 
independently of configured transport. Transport can be applied in 
the end, using command UASPC. Only one SAID can be applied 
for specified SP. In the example case SAID parameter is added later 
using UASPC command: 

UASPI : SPID=SPX1 , SPTYPE=SGP, PROT=SUA, 

SGID=SPX1 ; 

UASPI : SPID=SPX2 , SPTYPE=SGP, PROT=SUA, 

SGID=SPX2 ; 

UASPC :SPID=SPX1, SAID=SPXSUA1 ; 

UASPC :SPID=SPX2, SAID=SUASPX2 ; 

The UASPI command represents the SPXes in the MSC blades. 
Once the SPXes are defined in the MSC Blades, there is no need to 
define the them later on and they will be used further for the other 
definitions as well. 

Signaling Process Relation Definition: 

Once AS with its Routing Key and remote Signaling Process are 
defined, the remote Signaling Process relation with AS must be 
initiated. The type of AS and the type of remote Signaling Process 
must form a valid pair (ASP-SGP). 

One remote Signaling Process can be assigned to more than one 
AS. 

The remote Signaling Process relation with AS is initiated by 
means of command UAPRI. 

The command UAPRI is mandatory in ASP. 

The parameters in command are: Signaling Process identifier, 
protocol type, AS local identifier and Routing Context. 

UAPRI : SPID=SPX1 , ASID=AS2099, PROT=SUA, 

RC=2 0 9 9 ; 

UAPRI : SPID=SPX2 , ASID=AS2099, PROT=SUA, 

RC=2 0 9 9 ; 
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• SCTP End point Initialization 

IHBII:LIP= “192.168.1.103”, EPID=SUASEP01 , USER=SUA, 
MODE=CLIENT, SCTPCP; 


■ SCTP Association Data Definition 

IHADI:SAID=ASPSUA1, EPID=SUASEP01 , RIP=“1 92.168.1. 201” & 
“192.168.1.202”, SCTPCP; 


Figure 4-12: Signaling Transport MSC Blades 

■ AS definition: 

UAASI:ASID=AS2099, SPTYPE=ASP, DPC=99, Nl=2, PROT=SUA; 

■ SPC Definition for Remote Destination in SUA Network: 

UANPI:SP=2-1 00, ASSP=2-099; 

Definition of Network Subsystem (SSN) Related to Remote Destination in SUA: 

UANSI :SP=2-1 00,SSN=6; 

• Remote Signaling Process Definition: 

UASPI:SPID=SPX1 , SPTYPE=SGP, PROT=SUA, SGID=SPX1; 

UASPI:SPID=SPX2, SPTYPE=SGP, PROT=SUA, SGID=SPX2; 

UASPC:SPID=SPX1 , SAID=SPXSUA1 ; 

UASPC:SPID=SPX2, SAID=SUASPX2; 

• Signaling Process Relation Definition: 

UAPRI:SPID=SPX1 , ASID=AS2099, PROT=SUA, RC=2099; 

UAPRI:SPID=SPX2, ASID=AS2099, PROT=SUA, RC=2099; 

Figure 4-13: SUA Definition MSC Blades 

The relation between ASP and SGP in SG and AS nodes behavior 
is show below: 
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Figure 4-14. Summary relation between SGP and ASP 
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GCP OVER SCTP 

Since MSS R5.0 GCP can be implemented over SCTP directly. 
This conforms to the 3GPP specifications requiring GCP/SCTP for 
pure IP networks, while opening up the option of using M3UA in 
mixed ATM/IP networks. For an Ericsson MSC-S to interoperate 
with multi- vender M-MGWs it is necessary for GCP to be 
transported over SCTP. 

There are no different protocol variants (ITU-T, ANSI, MPT, TTC) 
as far as GCP, SCTP and IP are concerned. 

As a means to transfer GCP protocol directly over SCTP, STC 
(Signaling Transport Converter) is used. 

The STC entity is not visible in the network, i.e. it has no peer end 
to communicate with, but it helps signaling applications to stay 
independent on a transport level technology utilized between the 
network’s nodes. 

The MSC-S BC node can handle GCP/SCTP/IP and 
GCP/M3UA/SCTP/IP stacks at the same time, as long as they are 
used towards different virtual M-MGWs. 

The following figure shows protocol stacks seen through the 
messages exchanged in the network (i.e. no STC in peer to peer 
communication is visible): 




Note: In this case the blades use the External VLANs (2001 and 2002) IP Addresses. 

Figure 4-15: GCP over SCTP MSC and TSC Blades 

The GCP Transport over SCTP feature provides a GCP transport 
service that is based on end-to-end SCTP associations between an 
MSC Server and an M-MGW. The SCTP multi-homing 
mechanism provides reliability in the form of multiple paths that 
are established through the IP backbone. 
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In networks, where Signaling Gateways are used MSC Server and 
the M-MGW, the M3UA layer is needed to handle the inter- 
working towards MTP3b. In a full IP environment, the M3UA 
layer adds no value and can therefore be omitted. 

DATA TRANSCRIPT FOR GCP OVER SCTP 

The M-MGW is defined only in the MSC and TSC Blades. In this 
case the GCP signaling pass directly to the ISER (IS Router) and 
not through SPX nodes. No M3UA routing is needed. 

■ SCTP End Point Initialization: 

IHBII:LIP=“1 0.2.1 1 1 ,3”& “1 0.2.1 1 1 ,67”,EPID=EMGW1 , USER=GCP, 
SCTPCP, MODE=SERVER,LPN=2945; 

LPN: local port number for GCP over SCTP, if not given = 2945 for 
binary encoding, when user=GCP 

■ SCTP Association Data Definition: 

IHADI:SAID=BLD1 MGW1 ,EPID=EMGW1 , RIP=“10.3.9.20”& 
“10.3.9.148”, SCTPCP; 

OS (Outbound Streams): Not to be more than 16 for GCP over SCTP. 
Mode: server/peer, when GCP is the EP user, default for MSC-S is 
server MODE and peer is not allowed. 

Command IHASC:SAID=said,proc=estb; IS NOT USED for GCP over 
SCTP. 

Figure 4-16: Data Transcript for GCP over SCTP MSC and TSC Blades 

■ M-MGW Definition using GCPoSCTP: 

NRGWI:MG=CMGW6, BCUID=2610, SIGTR=SCTP, 
SIGADDR=BLD1 MGW1 ; 

Figure 4- 1 7: M-MGW Definition MSC and TSC Blades 
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5 MSC-S BC Features 


Objectives 


List the most common features in Mobile Softswitch Solution^ 
R5.2 accordingly to system documentation. 


■ List the new sets of data necessary to define the Call Set up in 
the MSS architecture for MSC-S and Media Gateway. 

■ Write the exchange data for M-MGW definition in MSC-S BC. 

■ Define remote TDM devices, MGW selection, BICC and GCP 
data in the MSC-Server BC. 

■ Illustrate the MML required for basic traffic case using TFO, 
TrFO and Codec at the Edge. 

■ Write the MML required in the MSC-S BC to implement the 
MSC-S BC in Pool. 




Figure 5- 1 . Objectives 
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MOBILE SOFTSWITCH SOLUTION 

The layered architecture as described by 3GPP R6 changes the 
current vertically specialized network (where different applications 
have their own access, transport, and control nodes for traffic 
handling) into a horizontally layered structure. This layering means 
in practice that the different levels in network hierarchy are 
separated, and communicate over well-specified interfaces. Thus 
different applications can share the resources in the lower levels of 
the network. 

The layered architecture is implemented by Ericsson as the Mobile 
Softswitch Solution (MSS) in the Mobile Network. The MSS 
presents a seamless network to the user by the merger of GSM and 
WCDMA networks, this enables the operator to offer quality 
services for voice, data and multimedia in the most cost-effective 
and resource efficient way. The seamless network solution is 
composed of multimode handsets that work both GSM and 
WCDMA frequencies and a network that combines the GSM and 
WCDMA resources like the common connectivity layer. The MSS 
comprises of two nodes the MSC-Server on the Control layer and 
the M-MGW on the connectivity layer. 

The MSS R5.2 uses the MSC-S Blade Cluster R13.1. 

Ericsson MSC-S Blade Cluster is a state of the art processor system 
for MSC Server. It features a multi processor using blade 
technology, which provides very high capacity, scalability and 
outstanding node availability. MSC Server Blade Cluster scales 
easily to very high capacity nodes while at the same time 
significantly increasing the node resilience. This is allows for an 
impressive network simplification and creating a network 
infrastructure that is easy to manage, always available and capable 
of adjusting to unpredictable future traffic increases and changing 
business needs. 

MSC Server Blade Cluster is an evolution of the successful MSS 
software being made available on state of the art generic single- 
sided processor blades that are grouped into a cluster. The cluster 
infrastructure is provided by utilizing the components of Ericsson’s 
Integrated Site Infrastructure. 
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The MSC Server is available on Blade Cluster state-of-the-art, 
modern HW architecture. MSC server processor blades are 
provided for traffic handling and signaling proxy (SPX) for 
handling the interface towards external network. MSC server 
blades form a multi processor cluster. The MSC Server Blade 
Cluster is implemented using the cluster concept and the Integrated 
Site (IS) infrastructure which allows co-location with IMS and 
other TSP based applications in the same node. 


The benefits achieved with the blade cluster based MSC Server 
system are coming from the clustering of processor blades and 
from using the Integrated Site infrastructure. MSC Server Blade 
Cluster is a multi processor system containing a signaling proxy 
and several processor blades and an I/O system. 


MSC-S Blade Cluster 


n+m redundancy 



SCTP/IP 1:n relation 




Figure 5-2. MSC Server Blade Cluster architecture 


The processor blades within an MSC Server form a blade cluster 
using single-sided AXE CP processors. There are two different 
kinds of blades, MSC blades handling the traffic and TSC blades 
handling the connections towards other the core network nodes and 
networks. 
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The MSC blades share the load of the MSC Server Blade Cluster 
i.e. distributes the subscribers over all MSC blades within the 
cluster. Distribution happens at initial location updating. The 
criteria to distribute the subscribers are the IMSI or IMEI of the 
subscriber and the capacity defined by load vector per each MSC 
blade. Each subscriber registered in the VLR is replicated over two 
different MSC blades (primary and secondary blade) for resilience. 

The TSC blades are provided for the connections towards the other 
core network nodes and other networks using ISUP, BICC or SIP. 
These blades do not hold any subscribers. 

The Signaling Proxy in the cluster is used as an aggregation node 
for C7 interfaces towards a broadband IP/SCTP interface. 
Signaling proxy converts and routes signaling traffic received from 
external network nodes to the MSC Server Blade Cluster. Signaling 
Proxy hides the blade cluster concept from the external network 
point of view. Signaling proxy will distribute the new subscribers 
round-robin between MSC blades which will then further distribute 
the subscribers to the primary blade and secondary blade. Always 
two signaling proxies per MSC Server Blade Cluster are included 
in order to facilitate the n + m redundancy. 

Redundancy and resilience of MSC Server blades is achieved by 
means of an “n + m” model which means that if a single processor 
blade fails the blades remaining in service take over the traffic. 
Each subscriber is assigned a blade pair, namely primary and 
secondary blade in which the subscriber data is stored. All traffic is 
directed to primary blade in the first place. In case primary blade is 
not available (planned or un-planned), traffic will be handled by the 
subscriber’s secondary blade. This kind of resilience is achieved by 
subscriber VLR data replication mechanism, which makes sure that 
semi- static and dynamic data pertaining to a certain mobile 
subscriber is available always in two blades. Due to this 
mechanism it is possible to isolate a blade from traffic, perform an 
upgrade or update and open the blade again for traffic without any 
traffic disturbance. 

In case one blade fails completely the self healing process will re- 
distribute the subscribers between remaining blades. 

Redundancy summary of the different components 

• SPX, 1+1 node protected, plus 1+1 network protected 

• MSC blades, n+1 protection 

• TSC blades, 1+1 protection on network level 

• APG 43, 1 + 1 node protection 
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• SIS, 1+1 node protection 

The MSC Server Blade Cluster is well suited to manage capacity 
since processor blades can be added to the cluster when more 
capacity is needed and during a live operation. 

As well as MSC Server Blade Cluster can be used as an extension 
to already installed servers or as a member of MSC pool in 
network. 

MSC Server Blade Cluster is implemented in the same, common 
application SW (dump) as the classical MSC Server. Therefore 
MSC Server Blade Cluster is using same O&M procedures as 
classical MSC server. 

I/O system is APG43. Separate I/O systems can be used for MML 
commands for blades, charging and statistics. 

MSS CORE NETWORK OVERVIEW 
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Figure 5-3: Core Network Overview 


The M-MGW connects the Mobile Core Network with external 
networks such as WCDMA and GSM Radio Access Networks, 
PSTN Networks or other Mobile Networks. With M-MGW, the 
layered network architecture can be fully implemented for circuit- 
switched traffic. MSC Servers remotely control the M-MGW using 
the Gateway Control Protocol (GCP) that is based on the ITU-T 
H.248 standard. The M-MGW makes IP, ATM and TDM transport 
possible in the backbone network for both the circuit- switched 
payload traffic as well as for the signaling. For WCDMA packet- 
switched traffic the M-MGW cross-connects the ATM-based user 
and control traffic to the SGSN node. 
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In addition to providing inter-working between different transport 
technologies, the M-MGW also provides advanced speech and data 
processing capabilities. 

SYSTEM OVERVIEW 

The M-MGW consists of the Media Gateway Application and 
Signaling Gateway Application built on top of the Ericsson 
Connectivity Packet Platform (CPP). 

Media Gateway Application 

The Media Gateway application consists mainly of the functions 
related to communication with the MSC/TSC Server(s), processing 
of the payload and inter-working between different transport 
technologies on Connectivity Layer. 


IP(NbUP,RTP) 


ATM(AAL2) 

Q.AAL2 


TDM 


Figure 5-4: M-MGw System Structure 

Signaling Gateway Application 

The Signaling Gateway Application supports a number of functions 
related to SS7 signaling, such as Signaling Gateway, Signaling 
Transfer Point and SCCP Relay Point. The Signaling Gateway 
(SGW) function relays SS7 messages between TDM/ATM-based 
SS7 signaling networks and IP-based SS7 networks. Message 
routing between SS7 signaling data links of the same or different 
types is carried out by the Signaling Transfer Point (STP) function. 
The routing of messages in the Signaling Transfer Point is 
performed on MTP layer 3 level and is based on Destination Point 
Code (DPC) and Network Indicator (NI). 
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The STP supports the routing, based on DPC and NI, of signaling 
messages between: 

• ATM and ATM links 

• TDM and TDM links 

• TDM and ATM links (MTP3 and MTP3b inter-working) 

• IP and ATM links (M3UA and MTP3b inter- working) 

• IP and TDM links (M3UA and MTP3 inter- working) 

The STP requires that at least one signaling point code in the SS7 
network is allocated to the node. Multiple point codes and network 
indicators are also supported, e.g. in network scenarios where the 
Signaling Transfer Point needs to be part of several SS7 networks. 

The Signaling Gateway Application also supports SCCP relay as an 
optional feature. SCCP relay makes it possible to route SS7 
messages within the same or different signaling networks based on 
Global Titles. 

HARDWARE STRUCTURE 

The M-MGW is based on the Ericsson Connectivity Packet 
Platform (CPP). The transmission support can easily be upgraded 
to match the applicable regional standard variant either by a SW 
upgrade or by adding or changing transmission boards. The robust, 
distributed multi-processor real-time telecom control system is 
built on the OSE Delta operating system. 

The TDM/ ATM/IP transport system of CPP includes a switch and a 
number of line interfaces. The internal switch has a duplicated 
switch core and a switch port on each board. The line interface 
boards provide the physical connection to TDM, ATM and IP 
bearers. The switch is controlled by the application Software via an 
API in the control system, or via standard signaling on the line 
interfaces. Extensive ATM functionality (ATM Cross-Connect, 
AAL2 for signaling and multiplexing, TDM Circuit Emulation and 
Inverse Multiplexing for ATM), as well as IP host functionality, is 
built into the platform. 
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The M-MGW is built in Generic Equipment Module (GEM) 
cabinets using CPP hardware arranged in a number of subracks 
mounted inside the cabinet. Each M-MGW subrack is configured 
with a number of plug-in-units such as Switch Core Boards (SCB), 
General Purpose Boards (GPB), Media Stream Boards (MSB) and 
Exchange Terminal (ET) boards of various kinds, all attached to a 
common backplane. This hardware structure provides a highly 
fault-tolerant node, which is easy to expand. 

GMP V3 has 7 Basic Configurations: 

• BC 3001, BC3002, BC3003, BC3004, BC3024, BC3051, 
BC3052. 


20 155 Mbps ATM ports (optional), 

4 155 Mbps TDM Port (optional), 

2 155 Mbps ATM/TDM ports (optional) 


Media Stream processing devices, 
4 155 Mbps TDM ports, 

6 155 Mbps ATM ports (optional), 
2 155 Mbps TDM ports (optional), 
2 Gbit Ethernet ports (optional) 

Processor, Inter Subrack Link 
connections and Timing HW, 

8 E1/T1 ATM/TDM ports 

Media Stream processing devices, 
4 155 Mbps TDM ports, 

6 155 Mbps ATM ports (optional), 
2 155 Mbps TDM ports (optional), 
2 Gbit Ethernet ports (optional) 



Stream processing devices, 
4 155 Mbps TDM ports, 

6 155 Mbps ATM ports (optional), 
2 155 Mbps TDM ports (optional), 
2 Gbit Ethernet ports (optional) 

Media Stream processing devices, 
4 155 Mbps TDM ports, 

6 155 Mbps ATM ports (optional), 
2 155 Mbps TDM ports (optional), 
Gbit Ethernet ports (optional) 


Figure 5-5: GMP V3.0 Configuration 3024 


TRAFFIC HANDLING 

Depending on network topology and the situation the M-MGW is 
handling, the node can assume different roles in the Mobile Core 
Network. It is not necessary to have several physical M-MGW 
nodes to take care of these different situations; one node can have a 
number of roles in the network. 



Figure 5-6: MGw in Traffic Handling 
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M-MGW as a Media Gateway 

The M-MGW contains a full set of speech and data resources for 
performing modifications and additions to the Connectivity Layer. 
It also contains transport resources for performing protocol and 
Connectivity Layer conversions between different transport 
technologies (ATM, IP and TDM). These qualities of the M-MGW 
pertain to the entity known as Media Gateway in standardization, 
and MSC Servers on the Control Layer utilize the H.248-based 
GCP to control the actions performed on the Connectivity Layer by 
M-MGW acting as Media Gateway. 

Example 1: When handling calls entering from the WCDMA 
network on the left and going to the ISDN/PSTN network on the 
left, MGW 1 in acts as a Media Gateway, changing the bearer from 
ATM to TDM and speech coding from Adaptive Multi Rate (AMR) 
to Pulse Code Modulation (PCM). 

Example 2: Traffic from ISDN/PSTN on the left enters the IP Core 
Network via MGW1. If the subscriber being called is within the 
WCDMA Radio Access Network on the right, traffic must be 
forwarded through the Core Network on top of IP bearer (Nb) to 
MGW2. In this example both MGW1 and MGw2 act as Media 
Gateways. MGW1 performs Connectivity Layer actions such as 
echo canceling and speech coding to AMR, and alters the bearer 
from TDM to IP. MGW2 changes the bearer from IP to ATM. The 
MSC server node controls allocation of these tasks between 
MGW1 and MGW2 with the help of Out-of-Band Transcoder 
Control (OoBTC) signaling. 

Example 3: In case the operator has chosen to utilize Transcoder 
Free Operation (TrFO) in the Core Network, speech coding will 
only be carried out in the terminals of the subscriber in WCDMA 
Radio Access Network on the left and another subscriber in 
WCDMA Radio Access Network on the right when a connection is 
built between subscribers in question. Transmission of the payload 
in compressed format through the Core Network improves the 
speech quality and makes efficient use of backbone bandwidth 
possible. This kind of payload handling is possible on IP and ATM 
bearers; the only task for MGwl and MGw2 is to do bearer 
conversion between WCDMA Radio Access Network and Core 
Network, where applicable. 
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M-MGW as an AAL2 Switch 

For WCDMA access, the M-MGW can forward AMR-coded traffic 
right through the ATM Core Network over connections that are set 
up using Q. 2630. 2 (a.k.a. Q.AAL2) signaling. This helps the 
operators gain significant savings in network resource utilization, 
as the bandwidth required by AMR-coded speech is only a fraction 
of that of PCM-coded traffic. 

Example 1: For calls entering from the WCDMA Radio Access 
Network on the left and going to the ISDN/PSTN network on the 
right, MGW 1 acts as an AAL2 switch and sends the payload in the 
format used within the UTRAN (Iu) to the MGW2 on the other 
side of the Core Network. In this example, MGW2 acts as a Media 
Gateway. Please note that the Iu interface is terminated at MGw2, 
resulting in transcoder at the edge. 

M-MGW as a Signaling Gateway 

The M-MGW performs conversions between different signaling 
transport technologies and thereby contains the functionality of the 
logical node Signaling Gateway that appears next to MGwl and 
MGw2. In addition to signaling bearer conversions, the Signaling 
Gateway also offers Signaling Transfer Point and SCCP Relay 
functionality. 

Example: Control signaling for GSM traffic (BSSAP) is entering 
the Core Network from BSS on TDM bearer. M-MGW acting as a 
Signaling Gateway changes the bearer into IP (M3UA/SCTP/IP), 
and forwards the signaling traffic to the MSC Server. 

M-MGW as an ATM Cross-Connect 

The ATM Cross-Connect functionality in M-MGW can be useful 
for several purposes. 

Example 1: There are needs for the WCDMA access nodes such as 
the RNC to exchange information with the server nodes on Control 
Layer of the Core Network. In cases like this, the MGwl just 
forwards the ATM packets containing signaling information from 
WCDMA access to Control Layer and back. 

Example 2: The data traffic from WCDMA access handled by the 
GPRS support nodes in the Core Network is forwarded through the 
MGW 1 that acts as an ATM Cross-Connect. 
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The M-MGW can exist in operators’ networks also without the 
functionality of logical nodes Media Gateway and Signaling 
Gateway. When used in this manner, the M-MGW acts as a pure 
ATM Cross-Connect/ AAL2 switch for example in situations where 
the Mobile Softswitch Solution has not been introduced yet. 

MEDIA STREAM HANDLING 

The M-MGW contains a set of functions needed to support the 
circuit- switched speech services in WCDMA and GSM. With the 
help of these functions, the M-MGW can adapt the circuit- switched 
speech for transfer over different networks. Speech coding from 
PCM-coded voice to AMR-coded voice in WCDMA can be 
mentioned as an example. 

The Media Stream Handling functionality is implemented in 
pooled devices that can be configured to support any of the 
individual functions listed below. With the help of this unique M- 
MGW quality, the operator can maximize the use of scarce network 
resources, such as echo cancellers. 

A media stream device is a combination of software and hardware 
resources that performs Media Stream Handling. The software 
resources exist in the form of Media Stream Processing (MSP) 
software load modules. The hardware resources are in the form of a 
number of Digital Signal Processor (DSP) that exist on a MSB 
board. 

Media Stream Handling 

The fundamental Media Stream Handling functions are: 

• Speech Coder including AMR2 and G.711. AMR2 is the default 
speech coding/decoding algorithm for WCDMA; G.711 is used 
on 2G/PSTN connections. 

The AMR2 speech coder operates in different modes, and 
selects the mode on the basis of quality measurements on both 
the uplink and downlink radio channel. During a call, the mode 
can change. The rate in the uplink channel can be different from 
that in the downlink channel. The selection of the encoder 
output rate, "codec rate", is a trade-off between speech quality 
and robustness. The speech coder complies with 3GPP 26.071 

Codec rates supported in AMR2: 12.2 kbit/s, 10.2 kbit/s, 
7.95kbit/s, 7.40 kbit/s, 6.70 kbit/s, 5.90 kbit/s, 5.15 kbit/s, 4.75 
kbit/s 
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• Extended Full Rate (EFR) is the speech coder for GSM. The 
Speech Coder handles the conversion between G.711-coded 
speech and EFR-coded speech. 

• Echo Canceller attenuating the echo generated at the 
conversion between 4-wire and 2-wire transmission in the 
PSTN. 

• Multi-Party Call functionality for bridging speech connections 
between several end-users involved in the same conversation. 

• Tone Sender provides tones to be sent to end-users. 

• DTMF Sender/Receiver sending DTMF tones to the far end of 
the connection as requested by a mobile terminal. DTMF tones 
are received in conjunction with e.g. the Interactive Messaging 
function. 

• Interactive Messaging: informative messages on special 

conditions in the network or pertaining to the service in use are 
played to the end-users with the help of this function. 

• The Code Answer and Tone Sender (CAT) function is used for 
maintenance purposes. It provides the capability to send tones 
from the Media Gateway in case of test calls. CAT also makes 
it possible to loop back the user plane of test calls to the 
originating side. 

• Continuity Check (CC) is used to test the integrity of the 
speech path. In Common Channel Signaling systems, the 
speech channel and the signaling channel may take different 
paths in the network. Therefore, in order to verify that the 
operating conditions of the channel are acceptable, the CC 
function is used. 

Voice Quality Enhancement 

Two Voice Quality Enhancement functions are available in 
conjunction with active Echo Canceller. 

Lawful Interception 

Lawful Interception enables the monitoring of circuit- switched 
speech and data in the M-MGW. An MSC Server via the GCP 
controls the monitoring; M-MGW sends a copy of the speech and 
data to be monitored to the monitoring center over TDM or ATM 
connections. 
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Transmission at Nb interface 

M-MGW supports transmission of compressed speech-coded 
(AMR and EFR-coded) speech over the ATM and IP bearers on the 
Nb interface. This function requires introduction of Out-of-Band 
Transcoder Control (OoBTC) for speech services in MSC Server. 
Bandwidth efficiency is achieved by transmitting the more less 
bandwidth demanding compressed speech on Nb interface instead 
of 64 kbps requiring PCM-coded speech. Compressed speech- 
coded speech over Nb interface makes it possible to achieve: 

• Transcoder Free Operation (TrFO) for WCDMA mobile to 
mobile calls. TrFO improves speech quality and enables 
bandwidth efficient transport in core network. Improved 
speech quality is achieved by omitting the voice sample 
manipulation with transcoder. TrFO thus allows the transport of 
compressed information end-to-end for WCDMA mobile calls. 

• Transcoder at the edge for WCDMA calls; The voice sample 
transcoding is performed at the M-MGw located at the 
interconnection point of the core network 

• Voice compression for GSM speech traffic; The bandwidth 
efficiency can be achieved by transcoding the PCM-coded 
speech received to less bandwidth-consuming format over the 
core network. 

TRANSCODER FREE OPERATION 

Transcoder Free Operation is an outcome of 3GPP Out-of-Band 
Transcoder Control (OoBTC) procedures. The outcome of OoBTC 
procedures could be end-to-end transcoder free operation or 
transcoder at the network edge to PSTN or another PFMN. 

TrFO is controlled by the MSC Server on the call control plane and 
must be supported by the Media Gateway (MGw) on the user 
plane. MSC-S BC performs the negotiation and selection of the 
codec used in the user plane in establishment of the speech calls, 
while the MGw handles the user plane protocols and provides a 
speech connection without transcoding, whenever possible. 

TrFO (OoBTC) functionality applies in WCDMA with MSS for 
ATM or IP transport technologies. 

This feature supports the basic codec negotiation principles used 
only during the call set-up phase. 
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This feature supports UMTS_AMR2 (Set7) and UMTS_AMR2 
(Setl) modes in the Core Network. UMTS_AMR2 (Set7) is a 
single mode codec with 12.2 Kbps while UMTS_AMR2 (Setl) 
includes 12.2, 7.4, 5.9 and 4.75 Kbps modes. 

This feature enables the MSC Server to use Bearer Independent 
Call Control (BICC) CS2 signaling procedures to control and 
establish: 

• ‘Transcoder Free Operation’ for WCDMA to WCDMA calls - 
where the speech calls have no transcoders involved in the 
network. For mobile-to-mobile calls it means that speech 
encoding/decoding is only performed in the peer User 
Equipments (UE). 

• ‘Transcoder at the edge’ - where transcoder free link carry 
speech compression up to the point where the speech is 
decoded to G.711 (PCM 64 Kbps) e.g. speech calls to or from 
an external network with TDM transport. 



1(1) Supported Codecs (2) BICC 1AM with Codec List (AMR, G.711) (3) Supported Codecs (4) Selected Codec 
(5) BICC APM with Selected Codec (AMR) (6) Selected Codec (7) Bearer setup (8) UP init 


Figure 5-7: Transcoder Free Operation 


TRANSCODER AT THE EDGE 

• Transcoder at the edge: The transcoder is placed at the edge of 
the user plane where the voice is from AMR2 to G.711 (PCM 
64 Kbps) e.g. speech calls to or from a Point of Interconnect 
(POI) with TDM transport. Requires OoBTC to be active in the 
MSC-S. 
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Transcoder at the Edge: 

Transcoder is located at the interconnection to external network. 


Figure 5-8: Transcoder at the Edge 


Tandem Free Operation (TFO) 

The TFO feature in M-MGW enables transfer of compressed 
speech over the 64 kbit/s PCM-coded interface towards 2G BSS, 
PSTN or other PLMN, and within the core network. Together with 
the feature Compressed Speech on Nb. TFO enables bandwidth 
efficient transport and improves speech quality for GSM 
connections, and in certain cases for WCDMA connections. 

OoBTC has to be activated in MSC-S BC i.e. in the TSC Blades. 



PCM AMR PCM 


GSM Speech traffic is transported in compressed form 
by two additional transcoders in the core network. 


Figure 5-9: Tandem Free Operation - TFO 
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MSC SERVER DEFINITIONS FOR MSS 

Regarding the new network architecture, there is the split of call 
control and bearer control, implying the split of the MSC/VLR 
logical node into two logical nodes: MSC Servcr/VLR and the 
Media Gateway (MGW). 

With ATM/IP based core networks: 


• GCP is used for controlling the CPP based Media 
Gateways. 

• BICC is used for call control between the server nodes 

When using a TDM core network , N-ISUP is used for call control 
between the server nodes. No GCP or CPP based Media Gateways 
are needed, but a CPP platform working only as a cross connect is 
needed between the core network and the RNCs. 

GATEWAY CONTROL PROTOCOL 

The Gateway Control Protocol (GCP) is used by the MSC Servers 
to control remote resources in the MGW, for a physically 
distributed network. 

This includes controlling network access resources (i.e. 
GSM/WCDMA radio access network), creating connections 
between these network access resources in the transport network, 
and to insert devices (e.g. announcement machines) into the media 
stream. 

Supported protocol stack: 

• GCP/MTP3b/SSCF/SSCOP/AAL5/ATM 

• GCP/M3UA/SCTP/IP 

• GCP/SCTP/IP (MSS R5.0 and on) 

The GCP feature is enhanced since MSS R5.0 to support the open 
standard H248.1 3GPP TS 29.232. This allows the MSC-S to 
control multi- vender M-MGW. 

A new Ericsson Proprietary H.248 profile is introduced with 
support added for the new features in R13 (Mn interface, GCP over 
SCTP). The profile is referred to by the short name EP6. EP6 is 
based on OP2 and H.248. 1 version 2 with parts still aligned with 
EP5 

OP2 corresponds to 3GPP R6 release profile. 
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BICC (BEARER INDEPENDENT CALL CONTROL) 

Bearer Independent Call Control (BICC) protocol provides the 
signaling functions required to support ATM & IP Core Networks. 
It supports the full set of narrow band ISDN services. Although 
BICC is designed to have a similar message structure and message 
name as ISUP, they are not peer to peer compatible. The specified 
BICC protocol is used between "Serving Nodes". On the Nc 
interface. 





w 


MSC-S BC 
(TSC Blades) 



M 





ATM user plane 




Figure 5-10: BICC in Different Networks 

The Bearer Independent Call Control (BICC) feature provides a 
mechanism for transferring call control related data between MSC 
Servers. It is the defined, standardized call control protocol to be 
used in a layered architecture 

BICC signaling protocol can be deployed over different signaling 
transport technologies. BICC uses a Generic Signaling Transport 
Converter, which makes BICC independent of the signaling 
transport used: 

• BICC/MTP3b/SSCF/SSCOP/AAL5/ATM 

• BICC/M3UA/SCTP/IP 

BICC CS2 (capability set) is required to implement the Layered 
Architecture which separates the call control function from the 
bearer control function. BICC CS2 supports OoBTC (codec 
negotiation) between MSC-Servers which is required for TrFO, 
TFO and compressed speech in the core network. 
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BICC CALL SETUP CONCEPTS 

The network architecture assumed by BICC requires new 
terminology and procedures to be defined. Some of the more 
important terms to know are: 

• Call Instance Code (CIC) 

• Bearer setup direction 

• Codec negotiation 

• Notification 

• BICC tunneling 

Call Instance Code 

In an N-ISUP network, each PCM bearer channel is allocated a 
Circuit Identification Code (CIC). At call set-up, an incoming and 
outgoing circuit is seized and the respective CIC values are 
associated with a call instance within each node. 

Since the bearer resource (and hence the CIC value) is the same at 
each end of the transmission link, the CIC can be said to uniquely 
associate the call instances in both nodes. That is, when sending 
SS7 messages, a CIC value is sufficient information to identify the 
call instance to which the message belongs and also the physical 
bearer that will be carrying speech traffic into and/or out of the 
switch. 

The Mobile Softswitch Solution does not allow the notion of a 
physical circuit in the same way as N-ISUP, yet the call instances 
in each node must still be associated with each other in order to 
relate signaling messages to specific calls. 

For this reason, the Call Instance Code is defined. 

The Call Instance Code can be thought of as a “virtual” SS7 CIC - 
it does not correspond directly to a physical circuit, yet it ties 
together the call instances in each node. Unlike the N-ISUP CIC, 
the BICC CIC is four full octets in length. The total number of 
provisioned CIC values for any particular signaling association 
indicates the maximum number of signaling relations between the 
BICC peer entities; that is, the maximum number of BICC calls 
that can be simultaneously handled between two adjacent control 
servers. 
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It should be noted that where M-MGws peer with TDM / ISUP 
based vertically integrated network, Circuit Identification Codes 
and physical circuits are still used on the access side. This is the 
case of the TSC server having to map BICC call set-ups to 
Narrowband ISUP call set-ups. The physical circuit must still be 
indicated for calls to/from existing legacy ISUP networks. 

Bearer Setup Direction 

BICC call setup procedures may be classified according to the 
direction of the bearer set-up relative to the direction of call set-up. 
If the bearer is established in the same direction as the call set-up 
(that is, from the Initial address message (IAM) sender to the IAM 
receiver) as shown in figure below, the bearer setup is said to be in 
forward direction. 



IAM (action indicator forward) 

MSC Server 1 

MGW Selection • 

MSC Server 2 


APM (BCU ID) 



• MGW Selection 



ERQ / Request 


M-MGw 1 

IP 

ECF / Accept 

M-MGw 2 


Figure 5-11. Forward Bearer Setup 


If the bearer is set up in the opposite direction to the call set-up as 
shown in then the bearer set-up is said to be in the backward 
direction. 


4mmm 

• MGW Selection 


MSC Server 1 

mw 

IAM (BCU ID) 

MSC Server 2 


MGW Selection • 



APM 




ERQ / Request 


M-MGw 1 

w 

ECF / Accept 

M-MGw 2 


Figure 5-12. Backward Bearer Setup 
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Since MSS R5.0 release enhancements have been made to the 
MGW selection for Forward Bearer Setup, the selected MGW 
information can now be sent to the succeeding MSC-S (BCU-ID). 
This means: 

• Forward bearer set up can be used for all cases; there is no need 
to use Backward Bearer Set up for PSTN to WCDMA Access. 

• OoBTC can be used together with optimized MGW Selection. 



6. lu Bearer setup 


Figure 5-13: Backward Bearer Setup with BCUID Included in I AM 


Benefits 


The operator can use Forward Bearer Set up and still achieve a 

common MGW at the network edge for all call cases. 

• Optimal MGW selection for all call cases: Reduced number of 
MGW nodes involved in a call which reduces CAPEX 

• The ability to use the same bearer set up method (forward) for 
all call cases simplifies network configuration which reduces 
OPEX 

• Allows using optimized MGW selection together with OoBTC 
procedures; compressed speech in the Core Network and Codec 
on the Edge is achievable for any call (Codec negotiation 
requires Forward Bearer Set up). 
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MEDIA GATEWAY SELECTION 

Media Gateway selection enables a Server node to select a Media 
Gateway which is most suitable for a given traffic case. This is 
needed to perform flexible routing of the payload within the core 
network and to optimize the transmission bandwidth. 

The media gateway selection can depend on different conditions: 

• Type of access. 

TDM accesses l ik e GSM subscribers and ISUP or Chinese TUP 
trunks are connected to specific MGWs, which restricts the 
MGW selection. 

• Node configuration. 

MGWs can be grouped into Media Gateway Groups (MGGs). 

MGWs within a MGG can have priority over other MGWs in 
the same MGG. The MGG can be connected to a route. If a 
MGG is defined on a route then a MGW from this MGG must 
be selected. MGWs belonging to the same group must be able 
to serve calls towards a certain destination. No checks are 
performed in the server when the MGG is configured. 

• Information in the bearer independent call control signaling (for 

those cases where a preceding or succeeding network entity has 
already selected a media gateway). 

MGWs already selected by a preceding or a succeeding server 
are taken into account, if the information is available at the time 
of selection. 

• Availability of the media gateways. 

• BICC route configuration (bearer set-up direction). 

• The MGW selection result will be influenced by pre-requisite 
from other features (i.e. codec negotiation, which is used for 
the OoBTC feature, requires that the bearer set-up direction is 
“Forward Bearer Setup”. 

The most important general rules followed by the MGW selection 
are: 

1. The MGW selection is destination dependent. 

2. The Server will based on the configuration try to select a common 
MGW for the incoming and for the outgoing access of the call. If this 
is not possible, the Server will use different MGWs for incoming and 
outgoing access. 
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3. If the incoming access is a BICC trunk access the BCU-ID received 
from the preceding node in case of backward bearer set up will be 
taken into consideration during MGW selection. 

If the outgoing access is a BICC trunk access the BCU-ID ID 
received from the succeeding node in case of deferred MGW 
selection (forward bearer set up) will be taken into consideration 
during MGW selection. 

The Media Gateways are grouped in Media Gateway Groups 
(MGG). 

Media Gateways belonging to the same group can serve a call 
towards a certain destination. The MSC server can access the 
resources provided by the Media Gateway in that group by means 
of GCP signaling. The Media Gateways in a group have the same 
capabilities and should serve a common destination. 

A Media Gateway can belong to various Media Gateway Groups. 

After the Media Gateway Group for a certain call has been 
selected, the MSC Server can choose a dedicated Media Gateway 
from that group. 

This feature also enables external networks to be accessed directly 
via a remote Media Getaway. 

The existing command, EXRBC and the related parameter 
RGSPAR, used for definition of route data, will also be used to 
attach a Media Gateway Group to a route. 

New commands are introduced for: 

Media Gateway definition handling (NRGWI, NRGWE, NRGWP) 

Media Gateway manual blocking handling (NRGBI, NRGBE) 

Media Gateway Group definition handling (NRGGI, NRGGE, 
NRGGP) 

Data Transcript Example 

In the following data transcript examples you can check the BICC, 

ISUP routes definition and also the MGW node inside MSC-S 
Blade Cluster. 

Notice that the data transcript now needs to be specific for each 
part of MSC-S BC, that is one file for each MSC, TSC blades and 
SPX nodes. 

During the next text and figures they are representing just one 
MSC, TSC or SPX nodes. 
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Connection to another MSC-Server 

The MSC-S Blade Cluster can be connected with a Classical MSC- 
S or another MSC-S BC. Both cases BICC protocol is used. BICC 
protocol is handled by TSC Blades only. Analyze the figure below: 

■ Other MSC-S BC (TSC Blades): 

C7SPI:SP=2-2302; 

C7SPC:SP=2-2302,NET=IP; !TSC Blade 1 ! 

C7PNC:SP=2-2302, SPID=TSC2302; 

C7MLC:SP=2-2302, ML=LONG; 

C7SPI:SP=2-2602; 

C7SPC:SP=2-2602,NET=IP; !TSC Blade 2! 

C7PNC:SP=2-2602, SPID=TSC2602; 

C7MLC:SP=2-2602, ML=LONG; 

Figure 5-14: Definition to another MSC-S TSC Blades 

The external node (another MSC-S BC in this example) sees the 
MSC-S BC as an exchange with two different signaling point now. 
Two TSCs are used for load sharing and redundancy purposes. 

■ Route Definition: 

EXROI:R=BIA302O&BIA302l,DETY=BID,FNC=3,SP=2-2302; 

EXRBC:R=BIA302O&BIA302l,RGPAR=OoBTC-2; 

EXROI:R=BIA602O&BIA602l,DETY=BID,FNC=3,SP=2-2602; 

EXRBC:R=BIA302O&BIA302l,RGPAR=OoBTC-2; 

• Device allocation: 

EXDRI:R=BIA3020&BIA302I,DEV=BID-0&&-31,BCIC=0; 

EXDRI:R=BIA602O&BIA602l,DEV=BID-32&&-63,BCIC=32; 

• Deblock devices: 

BLODE:DEV=BID-0&&-31 ; 

BLODE:DEV=BID-32&&-63; 

Figure 5-15: BICC Routes TSC Blades 

BICC continues using the device concept in AXE. The BICC 
devices are software devices. Therefore commands that define 
routes and connect devices on the routes are also used for BICC 
(EXROI/E/P, EXRBC, EXDRI/E/P, EXDEP, STDEP, BLODEE). 
Note that BICC devices have no corresponding hardware 
connection. Thus device connection to SNT (EXDUI) is not 
required . 
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The parameter, BCIC, related to BICC is added to the command 
EXDRI. 

The EXRBC command changes the default values or adds new 
parameters to the given route. OoBTC-2 is used for outgoing routes 
only. 

OOBTC allowed on this route if TMR or USI is "speech" or 
"3.1kHz Audio". 

Please check the Application Information BID for more details. 

Signaling Transport Definition to another MSC-S 

The MSC-S BC uses VLANs internally to communicate to each 
part of its components i.e. MSC, TSC, SPX and so on. Also to 
separate the different traffic inside such as SS7 signaling, O&M 
traffic, Intro protocol, Cluster Handler and others. 

For SS7 Signaling between blades it is necessary to define the 
VLAN 1001, which is used for internal signaling between blades 
and SPXs. 

All the VLANS should be also defined in the IS nodes previously. 
The VLAN 1001 is also know as INT-SIG which is the parameter 
used in the blades. 

■ IP Connection in the TSC Blades (Internal VLAN): 

IH IFI :NVIF=INT -SIG; 

IHIFC:NVIF=INT-SIG, ADD, IP=1 92.1 68.1 .x, 

NETMASK=255. 255. 255.0, ARP=YES; 

■ SCTP End Point Initialization: 

IHBII:UP="192.168.1.x”,EPID=BL2SPX,USEFt=M3UA, SCTPCP, 
MODE=CLIENT, LPN=2905; 

■ SCTP Association Initialization: 

IHADI:SAID=BICC2SPX1 ,EPID=BL2SPX, RIP=“SPX1 IP1"&“SPX1 
IP2”, SCTPCP, RPN=2905; 

IHADI:SAID=BICC2SPX2,EPID=BL2SPX, RIP=“SPX2 IP1"&“SPX2 
IP2”, SCTPCP, RPN=2905; 

Figure 5-16: Signaling transport TSC Blades - Internal Communication 
between Biades/SPX 

The SCTPCP parameter indicates that the SIGTRAN here is 
defined for IP on CP and not for GARP (IP on RP). 

Below is showing the associations activation to/from SPX nodes. 
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■ SCTP Association Activation: 

IHASC:SAID=BICC2SPX1 , PROC=ESTB, USER=M3UA, SCTPCP; 
IHASC:SAID=BICC2SPX2, PROC=ESTB, USER=M3UA, SCTPCP; 

M3ASC:SAID=BICC2SPX1, PROC=ACT; 

M3ASC:SAID=BICC2SPX2, PROC=ACT; 

■ M3UA Routing Definition and Activation: 

M3RSI:DEST=2-2302,SAID=BICC2SPX1 ,PRIO=1 , BMODE=PEER; 
M3RSI:DEST=2-2602,SAID=BICC2SPX2,PRIO=1 , BMODE=PEER; 

M3RAI:DEST=2-2302; 

M3RAI:DEST=2-2602; 

Figure 5-17: Signaling transport TSC Blades 

The signaling pass through SPX nodes before reach the final 
destination that is the other MSC-S BC. 


The M-MGWs are defined in all MSC and TSC Blades. Follow: 

■ MGWs signaling points: 

C7SPI:SP=2-201; 


C7PNC:SP=2-202, SPID=MGW2; 

C7MLC:SP=2-202, ML=LONG; 

Figure 5-18: Definition of MGWs Common for MSC and TSC Blades 

The GCP signaling transport to the MGW is defined passing 
through SPX nodes that means that the GCP is using 
M3UA/SCTP/IP otherwise it could pass directly to the ISER node. 


Media Gateway Definition 


C7SPC:SP=2-201,NET=IP; IMGW1 

C7PNC:SP=2-201 , SPID=MGW1 ; 
C7MLC:SP=2-201, ML=LONG; 


C7SPI:SP=2-202; 

C7SPC:SP=2-202,NET=BOTH; 


IMGW2! 
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• IP Connection in the Blades (Internal VLAN): 

IHIFI:NVIF=INT-SIG; 

IHIFC:NVIF=INT-SIG, ADD, IP=192.168.1.x, 

NETMASK=255. 255. 255.0, ARP=YES; 

• SCTP End Point Initialization: 

IHBII:LIP="1 92.1 68.1. x”,EPID=BL2SPX,USER=M3UA, SCTPCP, 
MODE=CLIENT, LPN=2905; 

■ SCTP Association Initialization: 

IHADI:SAID=M3SPX1,EPID=BL2SPX, RIP=“SPX1 IP1"&“SPX1 IP2”, 
SCTPCP, RPN=2905; 

IHADI:SAID=M3SPX2,EPID=BL2SPX, RIP=“SPX2 IP1"&“SPX2 IP2”, 
SCTPCP, RPN=2905; 

Figure 5-19: Signaling transport MSC and TSC Blades (1/2) 

■ SCTP Association Activation: 

IHASC:SAID=M3SPX1, PROC=ESTB, USER=M3UA, SCTPCP; 
IHASC:SAID=M3SPX2, PROC=ESTB, USER=M3UA, SCTPCP; 

M3ASC:SAID=M3SPX1, PROC=ACT; 

M3ASC:SAID=M3SPX2, PROC=ACT; 

• M3UA Routing Definition and Activation: 

M3RSI:DEST=2-201 ,SAID=M3SPX1 ,PRIO=1 , BMODE=PEER; 
M3RSI:DEST=2-202,SAID=M3SPX2,PRIO=1 , BMODE=PEER; 

M3RAI:DEST=2-201 ; 

M3RAI:DEST=2-202; 

Figure 5-20: Signaling transport MSC and TSC Blades (2/2) 

As recommend in the Signaling User Guide for MSC-S BC, all 
M3UA traffic pass to SPX and then to the final destination. Note 
that the IP connection is slightly different as SPX nodes are Dual 
Side CPs type. 
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■ IP Connection used from SPX to/from Blades (Internal VLAN): 

IHI FI :VIF=ETHA-1 001 ; 

IHI FI :VIF=ETHB-1 001 ; 

IHIFC:VIF=ETHA-1001 , ADD, IP=1 92.1 68.1. y, NETMASK=255.255.255.0, 
ARP=YES; 

IHIFC:VIF=ETHA-1001 , ADD, IP=1 92.1 68.1. z, NETMASK=255.255.255.0, 
ARP=YES; 

■ SCTP End Point Initialization: 

IHBI I :LI P="1 92.1 68.1 .y"&"1 92.1 68.1 .z", EPID=IM3S390, USER=M3UA, 
SCTPCP, MODE=SERVER, LPN=2905; 

■ SCTP Association Initialization: 

IHADI:SAID=IM3BLD303,EPID=IM3S390,RIP="1 92. 168. 1.x", SCTPCP; 
IHADI:SAID=IM3BLD304,EPID=IM3S390,RIP="192. 168. 1.x", SCTPCP; 


Figure 5-21: Signaling transport SPX Nodes - Internal Communication 
between SPX/Blades 

The RIP (Remote IP Address) is the MSC and TSC Blades 
addresses. 

■ IP Connection used from SPX to/from Blades (Internal VLAN): 

IHIFI:VIF=ETHA-2001 ; 

IHIFI:VIF=ETHB-2002; 

IHIFC:VIF=ETHA-2001 , ADD, IP=1 0.2.1 1 1 .58, NETMASK=255.255.255.0, ARP=YES; 
IHIFC:VIF=ETHA-2002, ADD, IP=1 0.2.1 11.122, NETMASK=255.255.255.0, ARP=YES; 
IHRHC:VIF=ETHA-2001 ,DEFGW=1 0.2.1 1 1 .61 ,ADD,PREF=1 ; 

IHRHC:VIF=ETHA-2001 ,DEFGW=1 0.2.1 1 1 ,62,ADD,PREF=0; 
IHRHC:VIF=ETHB-2002,DEFGW=10.2.11 1.125, ADD, PREF=0; 
IHRHC:VIF=ETHB-2002,DEFGW=1 0.2.1 1 1 ,126,ADD,PREF=1 ; 

■ SCTP End Point Initialization: 

IHBII:LIP="1 0.2.1 1 1 ,58"&"1 0.2.1 1 1 .122", EPID=EPEXT, USER=M3UA, SCTPCP, 
MODE=SERVER, LPN=5000; 

■ SCTP Association Initialization: 

IHADI:SAID=EMSC2302,EPID=EPEXT,RIP=‘‘1 0.8.1 .30", SCTPCP; lAnother MSC-S BC! 
IHADI:SAID=EMSC2602,EPID=EPEXT,RIP="1 0.8.1. 121", SCTPCP; 
IHADI:SAID=EMGW201,EPID=EPEXT,RIP="10.10.1. 9", SCTPCP; !MGW! 

Figure 5-22: Signaling transport SPX Nodes - External Communication 
to others MSC-S, MGWs 

Now, the RIP here belongs to the IP Address of each external 
Nodes such as MSC-S, MGW1 . . . 
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SCTP Association Activation: 

IHASC:SAID=EMSC2302, PROC=ESTB, USER=M3UA, SCTPCP; 
IHASC:SAID=EMSC2602, PROC=ESTB, USER=M3UA, SCTPCP; 
IHASC:SAID=EMGW201 , PROC=ESTB, USER=M3UA, SCTPCP; 

M3ASC:SAID=EMSC2302, PROC=ACT; 

M3ASC:SAID=EMSC2602, PROC=ACT 
M3ASC:SAID=EMGW201, PROC=ACT; 

M3UA Routing Definition and Activation: 

M3RSI:DEST=2-2302, SAID=EMSC2302, PRIO=1, BMODE=PEER; 
M3RSI:DEST=2-2602, SAID=EMSC2602, PRIO=1, BMODE=PEER; 
M3RSI:DEST=2-201, SAID=EMGW201 , PRIO=1, BMODE=PEER; 

M3RAI:DEST=2-2302; 

M3RAI:DEST=2-2602; 

M3RAI:DEST=2-201; 


Figure 5-23: Signaling transport SPX Nodes - M3UA Routing 


■ MGW Definition in both MSC and TSC Blades: 

NRGWI: MG=MGW1, BCUID=201 , SIGTR=ITUMTP, SIGADDR=2-201 ; 

NRGWI: MG=MGW2, BCUID=202, SIGTR=ITUMTP, SIGADDR=2-202; 

■ MGW Group for ISUP route: 

NRGGI:MGG=ISUP, MG=MGW1 , RESTRICTED; 

■ Define a MGG with for RNC with Priority: 

NRGGI:MGG=RNC, MGP=MGW1, MG=MGW2, ANYMG; 

EXRBC: R=RNC10, RGSPAR=MGG-RNC; lOnlyforMSC Blades! 

MGG for BICC Routes (TSC Blades): 

NRGGI:MGG=“BICC”; 

EXRBC:R=BIA302O, RGSPAR=MGG-BICC; 

Figure 5-24: MGW & MGG Definition MSC and TSC Blades 

MGG Types: 

One MGW only in a RESTICTED MGG (TDM Access). 

One DEFAULT MGG per Node. 

The MG "MGW1" is marked as prioritized and is assigned to the 
already defined MGG "MGG3". 

The ANYMG specifies that any MGW defined in the Node can 
used if available, priority is given to MGW1 and MGW2. 

ANYMG is used with an ATM Backbone. 

Assign MGG to a Route 

EXRBC : R=ROUTE,RGSPAR=MGG-BICC ; 


Define Media Gateway Group 
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Assign Bearer Setup Direction to a Route 

EXRBC is used to modify the default setting for the bearer setup 
direction. The parameter FBBS (Forward Backward Bearer Setup) 
is used on outgoing BID routes. 

PBSD (Preferred Bearer Setup Direction) is applicable for incoming 
MUIUCM routes. The different values are explained in 

EXRB C :R= route, RGPAR=FBBS- ; 

For BICC I/O Routes & TDM Routes FBBS is used. 

• 0- Default Value 

• 1= Bearer Establishment in Forward Direction. 

• 2= Bearer Establishment in Backward Direction. 

For Incoming RNC routes PBSD is used. 

• BACKD (backward bearer setup) 

• FORWD (forward bearer setup) 


Here is showing the definition of ISUP route using the remote 
devices UPDR which are physically allocated in the M-MGW 
node. 

■ Definition of PSTN SP: 

C7SPI:SP=2-303,OWNSP=2-310; 

C7PNC:SP=2-310,SPID=PSTN1 ; 

Route definition: 

EXR0I:R=UPDR30&UPDR3I, DETY=UPDR, FNC=3, SMSUP4, SP=2-310; 
EXRBC:R=UPDR30,RGSPAR=MGG-ISUP; 

■ Remote device allocation: 

NTCOI:SNT=RTDMA-0,EXTP=2-2-0,MG=MGW1,SNTV=0 
NTCOI:SNT=RTDMA-1 ,EXTP=2-2-1 ,MG=MGW1 ,SNTV=0 

EXDUI:SNT=RTDMA-0,DEV=UPDR-0&&-31 ; 
EXDUI:SNT=RTDMA-1,DEV=UPDR-32&&-63; 

Figure 5-25: ISUP Route TSC Blades only 


Remote ISUP devices and Route 
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■ Device connections: 

EXDRI:R=UPDR30&UPDR3l,DEV=UPDR-2&&-31 ,MISC1=2; 
EXDRI:R=UPDR30&UPDR3l,DEV=UPDR-34&&-63,MISC1=34; 

EXDAI:DEV=UPDR-2&&-31 ; 

EXDAI:DEV=UPDR-34&&-64; 

NTBLE:SNT=RTDMA-0; 

NTBLE:SNT=RTDMA-1 ; 

BLODE:DEV=UPDR-2&&-31 ; 

BLODE:DEV=UPDR-34&&-63; 

Figure 5-26: Remote ISUP Devices Connection TSC Blades only 

The number of Els between MGW1 and PSTN should be divided 
evenly by the two TSC Blades in order to have load sharing 
properly as TDM devices for MSC-S BC is manually distributed. 

In this example, there just 2 Els between MGW1 and PSTN. 

A TDM device is a software representation in the MSC or TSC 
Blade. In case of UPDR is controlled by TSC and MRALT, by 
MSC Blades . It corresponds to a 64 kbit/s digital channel in 
MGW. The TDM device is usually connected to a route and a CIC 
(TUP and ISUP signaling). The TDM device keeps track of, for 
instance, the state of the channel (idle/busy) and blockings (remote 
and local hardware/maintenance blockings). 

A local control TDM device is used when a TDM device is related 
to a media gateway that is combined with the MSC Server. 

A remote control TDM device is used when a TDM device is 
related to a media gateway that is not combined with the MSC 
Server. 

A Remote control TDM device is also connected to a TDM 
Termination ID (in addition to CIC) according to H.248. 

From an operator point of view, a remote TDM access will be very 
similar to the local TDM access, but the hardware, with which it is 
associated, is external to the node. 

From an operational point of view, the remote TDM handling will 
make use of the existing route, device, CIC and SNT concepts (and 
consequently of the related commands e.g. NTCOI, EXDUI). 
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The association of a remote TDM access in a MGW with its logical 
representation in the MSC will be created by means of the external 
SNT (E-SNT). The E-SNT will be used to support the remote TDM 
access grouping. 
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MSC IN POOL 

INTRODUCTION 


The MSC Pool feature was introduced for GSM/WCDMA in the 
R11/R4 release. GSM R13 / WCDMA R7 supports MSC/MSC-S 
in the pool for GSM and WCDMA with the caveat of needing 
separate pools for each Radio Access type. The feature provides a 
more robust core network by eliminating the single point of failure 
i.e. one BSC/RNC connected to one MSC/MSC-S. MSC pool can 
be implemented for both the layered and Classical network designs. 
The layered architecture is best suited to MSC Pool 
implementation with Sigtran being the preferred signaling transport 
system. 

A MSC Pool is defined as a pool of MSC nodes linked to a number 
of BSC and/or RNC nodes. Each BSC/RNC is connected to each 
MSC node of the pool. 



Figure 5-27: MSC in POOL 


All MSCs within a pool need to be connected to all BSCs/RNCs, 
so links need to be set up between the nodes. 

All MSCs within a pool need to have the same BSC/cell - 
RNC/SAI related settings. 
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An MSC of the pool has no knowledge about the behavior of the 
surrounding MSC nodes, whether they belong to the same MSC 
pool or not. The MSC pool concept is mainly applicable for the 
BSC/RNC, as the BSC/RNC can see a pool of MSC nodes. 

Each MSC node in a pool shares the same service area with all 
other MSCs in the pool. If an MSC is removed from the pool the 
subscribers of the removed MSC will be distributed to the other 
MSCs of the pool. This feature provides MSC redundancy and 
improved network service availability. 

Each BSC / RNC in the pool is connected via the A interface / Iu 
CS interface to each MSC/VLR's of the pool. This is referred to as 
the A flex and Iu flex in the telecommunication community. 

When a subscriber roams into a MSC Pool Service Area, the 
involved BSC/RNC selects one of the MSCs in the pool according 
to pre-defined traffic distribution algorithm based on the capacity 
figures of the MSC’s in the Pool. The subscriber registers in the 
selected MSC and remains registered in the same MSC until he 
moves out of the MSC Pool Service Area. 

When the subscriber moves from one location area to another 
within the MSC Pool Service Area, the new BSC/RNC will be 
informed by the MS about the identity of the MSC where it is 
registered. In order to implement this functionality without impacts 
on the Mobile Stations, the TMSI is modified to carry the NRI. 

In case MS has roamed outside the MSC Pool Area there may be a 
need to fetch the IMSI and the security related data from the 
previous MSC. In order to find out the correct co-operating MSC 
within the pool, the old TMSI (NRI) is analyzed in the new MSC. 
In case the previous MSC is part of a MSC pool, then TMSI points 
out to so called proxy MSC of that MSC pool, which has 
knowledge of all MSC’s in this MSC pool. This proxy MSC relays 
the signaling between new MSC and the correct previous MSC. 

Note: BSC/RNC configurations have to be adapted to the MSC- 
Pool concepts. 
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SOME NEW CONCEPTS 
Neighboring MSC Group 

The MSCs in the neighboring MSC group are grouped together 
(max. 16) for administration purposes to distribute the inter-MSC 
handover/SRNS relocation (from outside the pool) in order to 
achieve a better load distribution. With the neighboring MSC 
group, it is allowed to distribute the inter-MSC handovers/SRNS 
relocations between the group members. 



Figure 5-28: Neighbouring MSC Group 


Network Resource Indicator (NRI) 

The NRI has been introduced to perform the MSC routing 
discrimination on BSC/RNC. The routing will be performed based 
on the NRI. 

The NRI is coded inside the TMSI. It has a configurable length 
between 0 to 10 bits, located within bits 14 to 23. The most 
significant bit (MSB) is bit 23. If the full 10 bits are not used as 
NRI values, then these bits are used for TMSI ‘sThe NRI length is 
configured by the operator and indicates the number of bits that 
shall be used for the NRI field. NRI univocally identifies a MSC 
within a Pool. The NRI value is inserted into the TMSI, so that it 
shall be possible to store it into the SIM card. The length 0 bits 
means that NRI is not in use and therefore MSC in Pool function is 
not in use. 

The NRI is given by MML command when taking a new MSC into 
the Pool. At least one NRI value has to be assigned to an MSC 
serving in an MSC pool. 
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There will be major disturbances in the pool traffic when changing 
the NRI length. Therefore, the planning of the NRI length must be 
done very carefully, taking into consideration the future expansion 
of the MSCs in order to avoid changes in the NRI length. The 
assumption is that the NRI length is stable and changes of NRI 
length are rare. 

A deleted NRI in the MSC/VLR shall force a re-allocation of a new 
TMSI with a new NRI at the next mobile originating procedure (for 
example location update, CM service request). 


TMSI 

Structure: 


Figure 5-29: Network Resource Identity NRI 
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MSC Pool Area 


The MSC pool area is a collection of BSC or RNC service areas or 
both that are served by one or more MSC nodes in parallel that 
share the traffic from the pool area. This area an MS can roam 
without a need to change the serving MSC node. A BSC/RNC 
service area must belong completely to the one or more MSC pool 
area(s).All the MSC nodes in such a pool area share the 
responsibility of handling all the MSs, in all the LAs of the pool 
area. 

Once the MS has entered a new pool area, in normal operation the 
MS is served by the same MSC as long as the MS roams within the 
pool area 


Proxy MSC 


The cooperating VLR functionality is also impacted when a pool is 
built, as several MSC/VLRs serve the same location area. A 
mechanism is needed to ensure that the MAP messages requesting 
the subscriber data reach the right (previous) VLR. The proxy 
MSC/VLR function has been introduced to provide this 
mechanism. An MSC/VLR supporting the proxy functionality is 
named proxy MSC/VLR. 
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Old MSC/VLR nodes or MSC/VLR nodes that are not configured 
with any knowledge of NRI values are not aware of that multiple 
MSC/VLR nodes can serve the same LA (s). They can only derive 
one co-operating MSC/VLR address for each LA and can therefore 
only contact one cooperating MSC/VLR for each LA. 

In networks that contains both: MSC in pool and old MSCs there is 
a need to introduce the ‘Proxy functionality’. This must be defined 
in at least one MSC/VLR node which has common LA in the pool. 

The proxy MSC/VLR relays signaling between two different 
MSC/VLR nodes. The proxy MSC/VLR will have the knowledge 
of all MSC/VLR addresses serving the same LA and all NRI values 
assigned to these MSC/VLR nodes. 

The proxy MSC has a table containing all NRIs used inside the 
pool with their associated MSC/VLRs so modifications in the NRI 
addressing space have to be done also in all the proxies of the pool 
in order to keep consistent data. When the proxy MSC receives a 
MAP message asking for the mobile station IMSI and 
authentication data, it will extract the NRI from the received TMSI 
and will redirect the message to the right VLR. 

Any MSC belonging to the pool can act as a proxy, provided that it 
has knowledge of the complete set of NRI with its correspondent 
MSC used in the pool. 

Co-operation VLR data handling 

In case the MS has roamed out side the MSC Pool Area there may 
be a need to fetch the IMSI and the security related data from the 
previous MSC. In order to find out the correct co-operating MSC 
within the pool, the old TMSI is analyzed in the new MSC. In case 
the previous MSC is part of a MSC pool, then TMSI points out to 
so called proxy MSC of that MSC pool, which has knowledge of 
all MSCs in this MSC pool. This proxy MSC relays the signaling 
between new MSC and the correct previous MSC. 

Load re-distribution 

The load re-distribution functionality enables operator to empty an 
MSC within the pool from the traffic in order to perform 
maintenance activities like updates, upgrades and migration 
without any traffic disturbance. After the maintenance this MSC 
can be again filled-up with traffic. This activity can be initiated by 
commands in the MSC. 
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Note: It has to be noted that when MSC pool contains MSCs with 
different level of functionality, e.g. during a SW upgrade, the end- 
user will get different level of service depending on which MSC he 
is connected to. 


Charging 


Charging will be handled in the MSC in which the subscriber is 
registered independent of the current location of the subscriber. 

DEFINITION IN MSC 

The MSC in pool functionality will be activated when defining an 
NRI length greater than 0. Also, definition of the NRI length and 
own NRI values should be done on every MSC that will belong to 
the pool. 

MGNDI : NRIL=6 ,NRI V = 1 &2&3 ; 

The command sets the NRI length to 6 and defines the NRI values 
1 and 2 and 3, up to 8 NRI’s can be defined per MSC. 

MGPTI: VLRADDR=4- 35 8 68765 ,NRI V = 1 ; 

The VLR address is given in international format. 

The specified VLR address is added to the Proxy Table along with 
the given NRI value. 

MGMGI:MSCG=MSCG, MSC=msclinpool; 

New MSCG is defined with MSClinpool as the first MSC 
belonging to MSCG in the MSC Server/VLR. 

MGMGI:MSCG=MSCG, MSC=msc2inpool; 

MSC2inpool is added to the existing MSCG in the MSC 
Server/VLR. MSCG contains now two MSCs. 
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■ NRI Definition: 

MGNDI:NRIL=6,NRIV=1 &2&3; 

■ Define Proxy table: 

MGPTI:VLRADDR=4-35868765,NRIV=1 ; 

■ Define neighboring MSC groups: 

MGMGI:MSCG=MSCG, MSC=msc1 inpool; 

■ Add MSC to the existing MSCG: 

MGMGI:MSCG=MSCG, MSC=msc2inpool; 

Figure 5-30: Definition in MSC 

New AXE parameters 


TMSI use is mandatory: 
TMSIPAR (parameter set: GSMMMSC) 


Value 

Effect 

Note 

0 

TMSI not allocated 

Default value 

1 

TMSI allocated only on encrypted 
connections 


2 

TMSI allocated on all connections 



Figure 5-31: Pool Network: Parameters (1 

TMSI use is mandatory: 
TMSILAIMSC (parameter set: GSMMMSC) 


Value 

Effect 

Note 

0 

TMSI allocated only once 

Default value 

1 

TMSI allocated every time when 
mobile subscriber changes location 
area 



Figure 5-32: Pool Network: Parameters (2) 


• ADMHOMS CP OOL 

Activation/Deactivation of the administration of the handover 
to MSC pool. 
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• MSCREQNUM 

Defines the maximum number of trials to select a target MSC 
from the neighboring MSC group. 

• OWNCNID 

Defines the own core network ID (CN-ID) of an MSC/VLR. 

• TIMNRICHGM 

Defines the time supervision value during the handling of the 
changes in the NRI list. 

Modified AXE parameters: 

• OWNMCCM 

Defines the own Mobile Country Code (MCC) of an MSC. 

• OWNMNCM 

Defines the own Mobile Network Code (MNC) of an MSC. 
New SAEs: 

• SAE 500, MCVLRD (APT SAE) 

Stores data for the Proxy Table. 

• SAE 62 9, MCVLRD (APT SAE) 

Stores store the cooperating VLRs belonging to the MSC Pool 
serving the location areas identified by their LAIs. 

• SAE 630, MCVLRD (APT SAE) 

Stores the NRI values associated to each cooperating VLR, 
defined for a LAI, belonging to the MSC Pool serving the 
location areas identified by their LAI. 

• SAE 36, MTMSIAN (APT SAE) 

Stores data for visiting mobile subscribers. 

• SAE 1141, MTRAN (APT SAE) 

Stores data for neighbouring Mobile Services Switching Centre 
Groups (MSCGs). 

Changed SAEs: 

• SAE 602, MCVLRD (APT SAE) 

Stores the Location Area Identity (LAI) defined per 
cooperating VLR. 

• SAE 60 3, MCVLRD (APT SAE) 

Stores the LAI digits used for defined LAIs. 

OSS-RC 3 supports MSC Pool in GSM 

The OSS-RC provides the following applications to support MSC 
in Pool: 
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Cell data configuration applications: 

• The consistent configuration of the NRI length and NRI values 
in the MSC and the BSC nodes in the pool. 

• Consistent cell data configuration in the pool (e.g. all MSC 
nodes in the pool have the same cell data). 

• The configuration of the pool parameters in the BSC. 

Performance management applications: 

• NWSA core network reports are defined for the MSC pool 
according to the NWS reference (Network Statistics Analyzer, 
Function Description). 

• GSM RAN reports aggregate and present BSC/cell 
performance data related to MSC nodes that belong to a MSC 
pool (data aggregation in reports but there is no counter 
aggregation in the database). 

Fault management applications: 

• A new object is available in FM for the MSC in pool. The 
FMX tool can be used to define rules to aggregate the MSC 
nodes alarms to the MSC pool object. 

GSM Proxy Pool 


The GSM MSC Pool Proxy feature makes it possible to build MSC 
Pools in networks where the Base Station Controllers don’t support 
the MSC Pool. 

This feature is applied in the MGW nodes and in the MSC-S 
should support the MSC in Pool feature as well. 

The MSC Pool concept is based on a load-sharing algorithm 
implemented in the BSCs. This algorithm will distribute the 
subscribers between MSC Servers in a pool at location updating 
with the purpose of loading the MSC Servers evenly, leading to 
significant cost savings and better ISP in the network. However, 
many non-Ericsson BSCs don’t support the algorithm in question. 
In this case, the GSM MSC Pool Proxy can handle the distribution 
of subscribers between MSC Servers according to the same 
standard algorithm as used in the BSCs. 

GSM MSC Pool Proxies and BSCs supporting the load-sharing 
algorithm can be supported simultaneously in an MSC Pool. 
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6 BSC/RNC Connection 


Objectives 



Demonstrate the BSC/RNC connection in the MSC-S BC. 


■ Write the BSC/RNC signaling data toward the Core Network. 

■ Create the BSC/RNC traffic route data toward the Core 
Network 

J 

Figure 6-1: Objectives 
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INTRODUCTION 

This chapter describes the configuration of the interface between 
the Core Network and the Radio Network Access nodes (BSC and 
RNC) in Mobile Softswitch Solution (MSS) or Layered 
Architecture (LA) Networks. 

First, it the BSC connection will be presented and later on the RNC 
connection. 

In Non-LA connection from MSC to BSC is called A interface and 
in the LA it is called Remote A interface as the BSC physical 
resources are connected in the MGW node but controlled by the 
MSC Server. 

Both cases the protocol used for control plane is BSSAR 

As MSC-S Blade Cluster is only applied to LA networks, NLA is 
not show here. 

The following diagram shows the network example: 



SP=2-2700 


Figure 6-2: Network Diagram 
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ROUTES SUPPORTING BSSAP PROTOCOLS 

The signaling protocol used towards the BSC is BSSAP. In NLA, 
BSC is connected directly to MSC via TDM (El/Tl) and just the 
same as those in prior releases, the device type is the MALT In the 
MSC-S Blade Cluster, the remote A interface uses the MRALT 
device type. 

The command MGBSI connects the BSC to the traffic routes. 

Cell data is connected to BSC1 and BSC2 using command: 

MGCEI:CELL =cell, CGI=cgi, BSC=bscl; 

MGCEIrCELL =cell, CGI=cgi, BSC=bsc2; 

Cell Global Identity (CGI ) defined as MCC+MNC+LAC+CI. 

REMOTE A-INTERFACE 

The M-MGW supports the Remote A-Interface in Layered 
Architecture Networks. This allows direct connection of the A- 
Interface to M-MGW instead of the MSC in Non-LA. The physical 
hardware belonging to the TDM termination group is controlled by 
the MSC-S Blade Cluster. In the M-MGW each El/Tl circuit is 
defined as a TDM Termination Group with a specific PCM System 
number .The logical representation of these termination groups is 
defined in the MSC-S BC using MRALT devices: with 
corresponding circuit identification codes (CIC) and connected to 
one incoming and outgoing BSC route. 

The block MRALT (Mobile Telephony Remote A-Interface Line 
Terminal) handles the maintenance and supervision of the TDM 
devices on the remote A-interface. 

The block inter- works with 32 channel (El) or 24 channel (Tl) E- 
SNT’s (external switching network terminal) of type RTDMA 
(remote TDM access). 

To reuse existing configuration procedures the concept of the E- 
SNT was introduced before. An E-SNT is related to a group of 
devices, where the devices are physically connected to the M- 
MGW. From a Data Transcript point of view the configuration of 
the remote A interface is very similar to that of the A interface 
connected to the MSC in NLA. 
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Figure 6-3: External -Switch Network Terminal 


A one to one relationship exists between the E-SNT and the TDM 
Termination Group in the M-MGW. Different MSC-S cannot share 
the same TDM devices, this introduces the Virtual Media Gateway 
concept. A specific TDM Termination Group belongs to one V- 
MGW. 



Figure 6-4: Remote A Interface 


A TDM Termination Group contains 32/24 TDM terminations. 
Each termination has a unique 32- bit termination ID. The next 
figure shows a way to derive the device number from the 
Termination ID. 

The Termination ID is for example received in a protocol analyzer 
trace. 

The first step is to convert the Hexadecimal Termination ID to a 
binary value. The coding of a Termination ID is described in the 
upper left area of the following figure. 
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After identifying the bits used for the PCM System Number, the 
resulting value can be checked with the help of the NTCOP 
command. 


010 -> TDM 
010 ~> El, 001 — >T1 
e.g. Termination ID = H'4800 B015 

= 010 010 000000000010110000000 10101 
TDM El 1408 21 

NTCOP : SNT=ALL ; 

SNT SNTV DEV EXTP MG 

RTDMA-29 0 MRALT-160&&-191 2-2- 1408 MGWl 

END 

Figure 6-5: Termination ID Structure 

The printout indicates MRALT (device 21) in this specific 
Termination Group and the M-MGW that contains the hardware. 

BSC CONNECTED TO TWO MGW 

The most important configuration steps for a BSC definition are 
listed. 

The first step is to define an M-MGW and connect it to a restricted 
Media Gateway Group. 

If redundancy is required, a second M-MGW has to be defined and 
connected to a second restricted Media Gateway Group. 

To implement the redundancy feature, a third Media Gateway 
Group is defined which will contain the sum of the two previous 
M-MGW’s, this Media Gateway Group is non restricted. 

The first route pair both incoming/outgoing routes of device type 
MRALT have to be defined and the restricted Media Gateway 
connected using EXRBC. 

This is repeated for the second route pair. 

The first route pair is connected to the BSC with command 
MGBSI. 

The second route pair is connected to the BSC using command 
MGBWI. 

The non restricted Media Gateway Group is then connected to the 
BSC with command MGBSC and parameter BSCMGG. 


Access (3 bits) 

TDM Transport (3 bits) 
PCM System No. (21 bits) 
Individual (5 bits) 
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NRGGI:MGG=MGWG1 ,MG=MGW1 , RESTRICTED; 
NRGGI:MGG=MGWG2,MG=MGW2, RESTRICTED; 
NRGGI:MGG=MGWG3,MG=MGW1 &MGW2; 


A 


EXRBC:R=R1o,RGSPAR=MGWG1 ; 
EXRBC:R=R2o,RGSPAR=MGWG2; 


MSC Server 


MGBSC:BSC=BSC1 ,BSCMGG=MGWG3; 


I 




A 


BSC 1 


MGWG1 



MGWG3 


MGWG2 


Figure 6-6: BSC Connected to Two M-MGW 

If the BSC is connected redundantly) via two M-MGw’s to the 
MSC Server, three MGGs have to be defined. 

The restricted Media Gateway Groups MGWG1 and MGWG2 are 
connected to the outgoing BSC routes Rio and R2o. The non- 
restricted group MGWG3 includes both M-MGws and is connected 
to BSC1 using command MGBSC. 


As every BSC served by the MSC Server Blade Cluster sees the 
cluster as a single node, the remote A-Interface routes to a given 
BSC must be defined consistently in every MSC blade. The A- 
interface traffic time slots are assigned by the MSC during traffic 
handling. These timeslots are identified by a unique CIC value per 
Signaling Point Code of the BSC. 

An equal distribution of CICs (traffic time slots) must be achieved 
by manual administration. All MSC blades can handle the same 
capacity. It is not allowed to activate the same CIC for the same 
destination point code more then once inside the cluster. This must 
be as well assured by administration. 

If this recommendation is not followed a call will fail when the 
same traffic time slot will be seized by another blade. 


TDM Devices distribution 
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Basically the remote A-Interface configuration shall follow the ADI 
Mobile Telephony Data: BSC and Remote A-interface 
Administration if no circuit pools are used. If circuit pools are 
used the ADI Mobile Telephony Data: BSC and Circuit Pool 
Administration for Remote A-interface. Details about the 
command handing and further OPIs are referred and described in 
the ADI. However in the ADI only explains administration aspects 
from one MSC blade or non clustered MSC server point of view, 
specific MSC Server Blade Cluster aspects are not described in the 
documents. 

Traffic measurements can be performed on a specific incoming 
external or outgoing route external or on a specific incoming and 
outgoing external route. Since outgoing external or incoming 
external routes might be located on different type of blades all A- 
Interface routes must be defined on TSC blades as dummy routes. 

As discussed in the previous course, there is calculation that should 
be done depending on the amount of El/Tl connected per BSC. 
The calculation itself is not shown here again but the DT example 
is detailed for both cases: regular and irregular distribution of 
MRALT devices. 


DATA TRANSCRIPT FOR BSC 



18 x El’s 



SP=2-2352 



Figure 6-7: BSC Connection Network Example 



Note that the main point here is the amount of El/Tl trunks 
connected between BSCs and MGWs. 


To define the route to BSCs, the EXROI command is used and to 
add the MGW node, EXRBC command using the parameter 


RGSPAR. 
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The non restricted Media Gateway Group is then connected to the 
BSC with command MGBSC and parameter BSCMGG. 

■ Common DT for all MSC blades; 

- Route definition 

EXROI: FUBSC10&BSC1I, DETY=MRALT, FNC=3, SI=SCCP, SP=2-2101; 
EXRBC: R=BSC10, RGSPAR=MGG-MGWG1 ; 

- BSC definition 

MGBSI: BSC=BSC1, R1=BSC10, R2=BSC1I; 

MGBSC: BSC=BSC1, BSCMGG=MGWG1 ; 

■ Then, distribute all the timeslots per MSC blades. In this 
case: 

- 8 x 30 channels = 240 voice channels 

- 240 channels / 4 blades = 60 channels per blade 

■ Now, connect the amount of devices to external SNT. 

Figure 6-8: Regular Distribution of MRAL T Devices 

Note that if the BSC1 is connected through two M-MGW then 
MGG would have both nodes i.e. it would include MGW1 and 
MGW2. 

The concept of External Switching Network Terminals (E-SNT) is 
also applicable to remote ISUP and Chinese TUP devices. 

The bearer setup direction is by default Backward Bearer Setup 
(not changeable). 

■ DT for MSC BladeO: 

NTCOI:SNT=RTDMA-21,EXTP=2-2-910,SNTV=0,MG=MGW1: 

NTCOI:SNT=RTDMA-22,EXTP=2-2-911,SNTV=0,MG=MGW1: 

EXDUI:DEV=MRALT-0&&-31,SNT=RTDMA-21; 

EXDUI:DEV=MRALT-32&&-63,SNT=RTDMA-22; 

■ DT for MSC Bladel : 

NTCOI:SNT=RTDMA-21,EXTP=2-2-912,SNTV=0,MG=MGW1; 

NTCOI:SNT=RTDMA-22,EXTP=2-2-913,SNTV=0,MG=MGW1; 

EXDUI:DEV=MRALT-0&&-31 ,SNT=RTDMA-21 ; 
EXDUI:DEV=MRALT-32&&-63,SNT=RTDMA-22; 


■ DT for MSC Blade5: 

NTCOI:SNT=RTDMA-21,EXTP=2-2-916,SNTV=0,MG=MGW1; 

NTCOI:SNT=RTDMA-22,EXTP=2-2-917,SNTV=0,MG=MGW1; 

EXDUI:DEV=MRALT-0&&-31,SNT=RTDMA-21; 

EXDUI:DEV=MRALT-32&&-63,SNT=RTDMA-22; 


Figure 6-9. E-SNT Definition 
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■ DT for MSC BladeO: 

EXDRI:R=BSC10&BSC1I, DEV=MRALT- 2 &&- 31 , MISC1 =2 ; 
EXDRI:R=BSC1 O&BSCI I, DEV=MRALT- 34 &&- 63, MISC1=34 ; 


■ DT for MSC Bladel : 

EXDRI:R=BSC1 O&BSCI I, DEV=MRALT- 2 &&- 31,MISC1=66 ; 
EXDRI:R=BSC1 O&BSCI I, DEV=MRALT- 34 &&- 63, MISC1=98 ; 


■ DT for MSC Blade4: 

EXDRI:R=BSC1 O&BSCI I, DEV=MRALT- 2 &&- 31 , MISC1 =130; 
EXDRI:R=BSC1 O&BSCI I, DEV=MRALT- 34 &&- 63, MISC1=162 ; 


■ DT for MSC Blade5: 

EXDRI:R=BSC1 O&BSCI I, DEV=MRALT- 2 &&- 31 , MISC1 =194; 
EXDRI:R=BSC1 O&BSCI I, DEV=MRALT- 34 &&- 63, MISC1 =226; 


■ Common for all MSC Blades: 

NTBLE... BLORE... EXDAI... BLODE.... 


Figure 6- 1 0: Devices Connection 

Here is shown the signaling definition necessary in the SPX nodes. 

All the signaling necessary in the BSCs, regarding SUA protocol 
for example was defined in the Signaling in MSC-S BC chapter. 

■ Common DT for SPX nodes 

C7SPP:SP=2-2101; 

C7SPI:SP=2-2101 ,OWNSP=<SPX>; 

C7PNC:SP=2-21 01 ,SPID=BSC1; 

C7NPI:SP=2-2101 ; 

C7NPC:SP=2-21 01 ,MSG=1 ,MTC=1 , HPCCON; Howards to BSC! 

C7HPI:HPC=2-2000; Howards to MSC Blades! 

IHBII:LIP=“<IP1 >"&“<! P2>",EPID=EP1 ,USER=M3UA; 

IHADI:SAID=ASSOC1 , EPID=EP1, RIP=“<MGwlP1>”&“<MGwlP2>", SCTPCP; 
IHASC:SAID=ASSOC1 , PROC=ESTB, USER=M3UA, SCTPCP; 

M3ASC:SAID=ASSOC1 , PROC=ACT; 

M3RSI:DEST=2-2101 , SAID=ASSOC1, PRIO=1, BMODE=PEER; 

M3RAI:DEST=2-2101, SAID=ASSOC1; 

■ DT for TSC blades 

- No definition is needed in these blades. 


Figure 6-11. Signaling Definition in SPXes 

As the BSC2 has different amount of El/Tl trunks connected to 
MGW (another MGW as well in this case), the DT is also shown 
here. 

Note that the amount of traffic timeslots per blade is different and 
the blades are sharing the control of some Els. 
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■ Common DT for all MSC blades; 

- Route definition 

EXROI: R=BSC20&BSC2I, DETY=MRALT, FNC=3, SI=SCCP, SP=2-2102; 

EXRBC: R=BSC20, RGSPAR=MGG-MGWG2; 

- BSC definition 

MGBSI: BSC=BSC2, R1=BSC20, R2=BSC2I; 

MGBSC: BSC=BSC2, BSCMGG=MGWG2; 

■ Then, distribute all the timeslots per MSC blades. In this case: 

- 1 8 x 30 channels = 540 voice channels 

- 540 channels / 4 blades = 1 35 channels per blade 

■ Note that 1 35 channels represent 4,5 Els. Connect the amount of 
devices to external SNT. 

Figure 6-12. Irregular Distribution of MRALT Devices 

From the E-SNT point of view, all the timeslots in the 5 th trunk are 
connected using the EXDUI command. 


All SNT names can be the same in all MSC blades, but the external 
point connection in the MGW node (EXTP parameter) must be 
different as it represents a single PCM system number in the MGW 
node. 


■ DT for MSC BladeO: 

NTCOI:SNT=RTDMA-31,EXTP=2-2-1031,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-32,EXTP=2-2-1032,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-33,EXTP=2-2-1033,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-34,EXTP=2-2-1034,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-35,EXTP=2-2-1035,SNTV=0,MG=MGW2 

EXDUI:DEV=MRALT-0&&-31 ,SNT=RTDMA-31 ; 

EXDUI:DEV=MRALT-32&&-63,SNT=RTDMA-32; 

EXDUI:DEV=MRALT-64&&-95,SNT=RTDMA-33; 

EXDUI:DEV=MRALT-96&&-127,SNT=RTDMA-34; 

EXDUI :DEV=MRALT-128&&-1 59,SNT=RTDMA-35; 


■ DT for MSC Bladel : 

NTCOI:SNT=RTDMA-31,EXTP=2-2-1036,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-32,EXTP=2-2-1037,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-33,EXTP=2-2-1038,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-34,EXTP=2-2-1039,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-35,EXTP=2-2-1040,SNTV=0,MG=MGW2 

EXDUI:DEV=MRALT-0&&-31 ,SNT=RTDMA-31 ; 

EXDUI:DEV=MRALT-32&&-63,SNT=RTDMA-32; 

EXDUI:DEV=MRALT-64&&-95,SNT=RTDMA-33; 

EXDUI:DEV=MRALT-96&&-127,SNT=RTDMA-34; 

EXDUI:DEV=MRALT-128&&-159,SNT=RTDMA-35; 


Figure 6-13. E-SNT Definition 
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■ DT for MSC Blade4: 

NTCOI:SNT=RTDMA-31 ,EXTP=2-2-1041 ,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-32,EXTP=2-2-1042,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-33,EXTP=2-2-1043,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-34,EXTP=2-2-1044,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-35,EXTP=2-2-1045,SNTV=0,MG=MGW2 

EXDUI:DEV=MRALT-0&&-31 ,SNT=RTDMA-31 ; 

EXDUI:DEV=MRALT-32&&-63,SNT=RTDMA-32; 

EXDUI:DEV=MRALT-64&&-95,SNT=RTDMA-33; 

EXDUI:DEV=MRALT-96&&-127,SNT=RTDMA-34; 

EXDUI:DEV=MRALT-128&&-159,SNT=RTDMA-35; 


■ DT for MSC Blade5: 

NTCOI:SNT=RTDMA-31,EXTP=2-2-1046,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-32,EXTP=2-2-1047,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-33,EXTP=2-2-1048,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-34,EXTP=2-2-1049,SNTV=0,MG=MGW2 

NTCOI:SNT=RTDMA-35,EXTP=2-2-1050,SNTV=0,MG=MGW2 

EXDUI:DEV=MRALT-0&&-31 ,SNT=RTDMA-31 ; 

EXDUI:DEV=MRALT-32&&-63,SNT=RTDMA-32; 

EXDUI:DEV=MRALT-64&&-95,SNT=RTDMA-33; 

EXDUI:DEV=MRALT-96&&-127,SNT=RTDMA-34; 

EXDUI:DEV=MRALT-128&&-159,SNT=RTDMA-35; 


Figure 6-14. E-SNT Definition (cont.). 


The devices are connected to BSC2 traffic route by using the 
EXDRI command. The parameter MISC1 represents the CIC value. 
As from BSC2 sees the MSC-S BC as a unique node, the CIC 
values should be equally distribute per blades. In the example, if 
we separate the timeslot 1 of each El for signaling purpose, 135 
traffic channels (CICs) will be controlled by each MSC blade. 


The CIC values will be sequentially considering all blades. The 
MRALT devices could be the same if it is not representing the 
shared trunk. The MSC-S nodes cannot control the same PCM 
system number. So for the same El/Tl when shared by different 
MSC blades, it should be defined another PCM system number (in 
the MGW) and another EXTP in the MSC Blade. 

The DT below shows that part of the El (devices from MRALT 
130 &&-144) is controlled by MSC Blade 0 and the other half 
(MRALT 145&&- 159) is controlled by MSC Blade 1. 

As MSC Blade 1 is another “node”, it can reuse the MRALT device 
numbers to represent another El in the A-interface. It could be use 
another range to make an easier comprehension but in this case the 
SAEs in all Blades should be much bigger and it will be useless. 
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■ 

DT for MSC BladeO: 

EXDRI:R=BSC10&BSC1 1, DEV=MRALT- 2 &&- 31, MISC1=2 ; 
EXDRI:R=BSC1 O&BSCI 1, DEV=MRALT- 34 &&- 63 , MISC1=34 ; 
EXDRI:R=BSC10&BSC1 1, DEV=MRALT- 66 &&- 95 , MISC1=66 ; 
EXDRI:R=BSC1 O&BSCI 1, DEV=MRALT- 98 &&- 127, MISC1=98 ; 
EXDRI:R=BSC10&BSC1 1, DEV=MRALT-130&&- 144, MISC1=130 ; 

■ 

DT for MSC Bladel : 

EXDRI:R=BSC1 O&BSCI 1, DEV=MRALT-145 &&-159, MISC1=145 
EXDRI:R=BSC1 O&BSCI 1, DEV=MRALT- 2 &&- 31, MISC1=162 
EXDRI:R=BSC10&BSC1 1, DEV=MRALT- 34 &&- 63 , MISC1=194 
EXDRI:R=BSC1 O&BSCI 1, DEV=MRALT- 66 &&- 95 , MISC1 =226 
EXDRI:R=BSC10&BSC1 1, DEV=MRALT- 98 &&- 127, MISC1=258 


■ 

DT for MSC Blade4: 

EXDRI:R=BSC1 O&BSCI 1, DEV=MRALT- 2 &&- 31, MISC1=290 
EXDRI:R=BSC1 O&BSCI 1, DEV=MRALT- 34 &&- 63 , MISC1=322 
EXDRI:R=BSC1 O&BSCI 1, DEV=MRALT- 66 &&- 95 , MISC1=354 
EXDRI:R=BSC1 O&BSCI 1, DEV=MRALT- 98 &&- 127, MISC1=386; 
EXDRI:R=BSC10&BSC1 1, DEV=MRALT-130&&- 144, MISC1=418 


Figure 6-15. Device connection 

■ 

DT for MSC Blade5: 

EXDRI:R=BSC10&BSC1 1, DEV=MRALT-145 &&-159, MISC1=433 
EXDRI:R=BSC10&BSC1 1, DEV=MRALT- 2 &&- 31, MISC1=450 
EXDRI:R=BSC10&BSC1 1, DEV=MRALT- 34 &&- 63, MISC1=482 
EXDRI:R=BSC10&BSC1 1, DEV=MRALT- 66 &&- 95, MISC1=514 
EXDRI:R=BSC10&BSC1 1, DEV=MRALT- 98 &&- 127, MISC1=546 


■ 

Common for all MSC Blades: 

NTBLE... BLORE... EXDAI... BLODE.... 

Figure 6-16. Device connection (cont.) 

Below, again the definition in the SPXes regarding signaling to 
BSC2. 

■ 

Common DT for SPX nodes 

C7SPP:SP=2-21 02; 

C7SPI:SP=2-2102 ,OWNSP=<SPX>; 
C7PNC:SP=2-2102 ,SPID=BSC2; 
C7NPI:SP=2-2102; 

C7NPC:SP=2-2102 ,MSG=1 ,MTC=1 , HPCCON; 


1 HBII:LIP=“<I PI >"&“<! P2>”, EPI D=EP1 ,USER=M3UA; 

IHADI:SAID=ASSOC2, EPID=EP1, RIP=“<MGw2IP1>"&“<MGw2IP2>", SCTPCP; 
IHASC:SAID=ASSOC2, PROC=ESTB, USER=M3UA, SCTPCP; 
M3ASC:SAID=ASSOC2, PROC=ACT; 

M3RSI:DEST=2-2102, SAID=ASSOC2, PRIO=1, BMODE=PEER; 
M3RAI:DEST=2-2102, SAID=ASSOC2; 

■ 

DT for TSC blades 

- No definition is needed in these blades. 

Figure 6- 1 7. Signaling definition in SPXes 


LZT 123 9083 R1 A 


© Ericsson 2009 


- 143 - 


MSC-S R13.1 Blade Cluster Data Transcript 


ERICSSON ^ 


BSC Redundant Connection 

In the case of alternative and additional routes, the commands 
MGBWI and MGBOI are used to connect outgoing and incoming 
Media Gateway routes to a BSC. Additional routes can only be 
connected with command MGBOI if a route pair with the same 
media gateway group is already connected to the same BSC. 

• Connect additional outgoing and incoming M-MGw 
routes pairs to an BSC: 

MGBOI : BSC=bsc, Rl=r 1 , R2=r2 ; 

(Additional routes can only be connected to the BSC if a route pair 
with the same media gateway group is already connected to the same 
BSC) 

• Connect alternative outgoing and incoming M-MGw routes to an 
BSC: 

MGBWI : BSC=bsc, Rl=r 1 , R2=r2 ; 

(no route pair is connected to the BSC towards the M-MGw) 
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The first route pair is connected when the BSC is defined 
(MGBSI). 

■ Connect alternative outgoing and incoming M-MGw routes to an 
BSC: 

MGBWI :BSC=BSC1 ,R1 =BSJC2o,R2=BSJC2i 


■ Connect additional outgoing and incoming M-MGw routes pairs to 
an BSC: 


MGBOI :BSC=bsc,R1 =r1 ,R2=r2; 


MGwl - SJC 



SP=2-501 

BSC - SJC 

X^-Avigbsi 


SP=2-601 

X^^MGBWI 




MGw2 - TTE 

See Al: MRCIPOA 

MGBOI — — — 

SP=2-502 


Figure 6-18: Connection of Additional & Alternative Routes to BSC 


Bearer Setup Direction 

For BSCs the bearer setup direction definition is not defined as a 
parameter connected to routes using command EXRBC. Instead it 
is defined as a BSC capability (PBSD), which can be set with the 
command MGBSC. 

■ Definition of Bearer Setup Direction: 

MGBSC:BSC=BSC1 ,PBSD=FORWD; 

The parameter PBSD can be either: 

- BACKD 

Backward bearer set up direction preferred 

- FORWD 

Forward bearer set up direction preferred 
Figure 6-19: Bearer Setup Direction 

Connection of Transcoders 

Transcoders are required to change the coding of the speech to be 
transmitted over the air interface. The most common types of 
coding exist: Full Rate (FR), Half Rate (HR) and Enhanced Full 
Rate (EFR). 

Traditionally, the transcoders have been controlled by the BSC. 
However, the Transcoders can be configured as a standalone node 
(TRC), placed on the A-Interface (Non-LA networks) or remote A- 
Interface (LA networks), but not under the BSC control. 
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SP=2-101 


Figure 6-20: Combined TRC/BSC and standalone BSC 

Where the standalone TRC is utilized a new interface, the Ater is 
introduced between BSC and TRC. Up to 15 BSC’s can be 
connected to 1 TRC. 


■ ROUTES TOWARDS THE BSC4: 

EXR0I:R=BSC40&BSC4I, DETY=MRALT, FNC=3, SI=SCCP, SP=2-100; 
!EXRBC:R=BSC40&BSC4I, RNO=1, MIS1 = 1, MIS2=1; 

!Pool no. 1 & Full Rate! 

EXROI:R=BSC4HRO&BSC4HRI, DETY=MRALT, FNC=3, SI=SCCP. SP=2-100; 
!EXRBC:R=BSC4HRO&BSC4HRI, RNO=1 , MIS1=2, MIS2=2; 

IPool no. 2 & Half Rate! 

EXROI:R=BSC4ERO&BSC4ERI, DETY=MRALT, FNC=3, SI=SCCP, SP=2-100; 
!EXRBC:R=BSC4ERO&BSC4ERI,RNO=1,MIS1=3,MIS2=4; 

IPool no3 & Enhanced Full Rate! 

EXROI:R=BSC4SO&BSC4SI, DETY=MRALT, FNC=5; 

Figure 6-21: Circuit Pool /Handling Towards BSC 
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■ BSC Definition: 

MGBSI:BSC=BSC4, R1=BSC40, R2=BSC4I; 

MGBSC:BSC=BSC4, BSCDATA=HRATE-1 ; 

MGBSC:BSC=BSC4, BSCDATA=NIRR-1 ; 

MGBSC:BSC=BSC4, BSCDATA=MSCODER-1 ; 

MGBSC:BSC=BSC4, BSCMGG=MGWG4; 

■ Devices connection: 

EXDRI:R=BSC40&BSC4I, DEV=MRALT-2&&-31 , MISC1=2; 
EXDRI:R=BSC4HRO&BSC4HRI, DEV=MRALT-34&&-63, MISC1=2; 
EXDRI:R=BSC4ERO&BSC4ERI, DEV=MRALT-66&&-95, MISC1=2 
EXDRI:R=BSC4SO&BSC4SI, DEV=MRALT-1 &-33&-65; 

Figure 6-22: Circuit Pool Handling Towards BSC (cont.) 

It can be seen from Figure above that three traffic routes are 
defined towards BSC4, one route supporting Full Rate, the second 
supporting Half Rate and the third supporting Enhanced Full Rate. 
This can be determined with the MIS2 parameter. Use the AI for 
MRALT. Each one of these routes is termed as a POOL and 
requires a unique number. The MIS1 parameter gives the Pool 
Number. Parameter RNO is an NMS function and would be used as 
a network Management function. 

Transcoder of type R6A is housed in the GEM magazine on the 
Common Speech Processor Board and will support TFO (Tandem 
Free Operation). In case MSS networks, the TRA are in the MGW 
nodes. 
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UTRAN INTRODUCTION 


UTRAN CONCEPT 


The WCDMA Radio Access Network (RAN) consists of Radio 
Network Controllers (RNC), Radio Base Stations (RBS), the OSS- 
RC and Tools for Radio Access Management (TRAM). RBS 
corresponds to Node B in the 3GPP specifications. Figure 6-2 
shows a complete RAN system concept. 


Figure 6-23: WCDMA RAN Basic Architecture 

The WCDMA RAN comprises Radio Network Controllers (RNCs) 
and Radio Base Stations (RBSs) built on the Connectivity Packet 
Platform (CPP). 

The main tasks of the RNC are to manage the Radio Access 
Bearers for user data transport, manage and optimize the radio 
network resources and control the mobility, while RBS provides 
the actual radio resources and maintains the radio links. 

To enable communication between the different Network Elements 
(NEs) in the WCDMA RAN and between the WCDMA RAN and 
the Core Network, different interfaces are defined and used. Over 
the interfaces, transport of signaling and user data is performed via 
a Transport Network Infrastructure using ATM or IP. 



Other 
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RNC is connected to the core network via the Iu interface and the 
User Equipment (UE) is connected to RBS via the Uu interface 
(the radio interface). Internally within RAN, the RNCs are 
interconnected via the Iur interface and the RBSs to the RNC via 
the Iub interface. 

OSS-RC is a set of software for handling operation and 
maintenance tasks for the WCDMA RAN. RANOS gives a 
consolidated view of the RAN information such as alarms, 
configurations and basic performance. It also provides several 
interfaces for easy integration with the existing management 
environment. 

The Tools for Radio Access Management (TRAM) gives support 
for planning, test and performance monitoring of the radio- and the 
transport network. The resulting configuration data from the 
TRAM design can, via RANOS, be downloaded to the nodes. 


IU INTERFACE 


Iu is the interface between the WCDMA RAN and Core Network. 
The Iu interface connects the RNC (via the MGW) to the MSC- 
Blade Cluster and the SGSN. The interface is therefore divided into 
two parts: 

• The Iu interface to the packet switched domain, i.e. to the 
SGSN, is referred to as Iu-PS. 

• The Iu interface to the circuit switched domain, i.e. to the 
MSC-S BC, is referred to as Iu-CS. 

The Iu interface supports several functions such as establishing, 
maintaining and releasing Radio Access Bearers (RABs), 
performing intra-system and intersystem handover, and location 
services by transferring requests from the CN to WCDMA RAN, 
and location information from WCDMA to CN. 

Radio Access Network Application Part (RANAP) is the protocol 
used over the Iu interface. The signaling transport can be either 
ATM or IP. 

Traffic circuit switched and packet switched is transported over 
ATM or IP. 
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SIGNALING TRANSPORT TO RNC 

In MSC-S Blade Cluster is possible to connect the RNC (via 
MGW) using IP or ATM. IP is a basic option and ATM is an 
optional. 

CONNECT RNC TO MSC SERVER 

In the following example the definitions are shown to connect an 
MSC-S Blade Cluster node via MGW with an RNC as shown in 
figure below: 




SP=2-2351 


18 x El’s 



SP=2-2352 IMSI : 262 55 30 000 00002 

MSISDN: +49 17 230 00002 



SP=2-3101 


SP=2-2353 



Node B 


PSTN 


SP=2-2354 \ 


ESI 


D 


IMSI: 262 99 30 000 50010 
MSISDN: +49 17 330 50010 


Figure 6-24: MSC-S BC RNC Connection 


IU-INTERFA CE 


Every RNC served by the MSC Server Blade Cluster sees the 
cluster as a single node, the Iu-interface routes to a given 
destination must be defined consistently in every MSC blade. As 
the MSC Server Blade Cluster will have a single Signaling Point 
Code visible for the RAN, the signaling connection to RNCs must 
be done thru the signaling proxy. 

Basically the Iu-Interface shall follow the ADI ‘Mobile Telephony 
Data: Radio network Controller’. 
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There is no specific administration aspects from one MSC Server Blade 
Cluster compared to classic MSC Server beside the fact that all data that 
belong to an RNC must be consistently setup on each MSC blades. 
This applies also for changes in the RNC configuration as well as for a 
removal of an RNC. 

The used resources in MGW to transport the traffic payload can be 
dynamically allocated to each MSC blade. There is no complicated 
manual distribution of “circuits” necessary for the Iu interface. 

Whenever new RNC routes are added dummy routes might be 
defined in the TSC blades using command EXROI with the same 
route name as defined previously in the MSC blades but using 
device type TRDRN. 

Inter MSC Handover and SR NS reallocation 

The E-interface has to be setup between the MSC Blades and the 
neighbor MSC nodes where Inter MSC Handover and SRNS 
reallocation shall be possible. Handover and SRNS reallocation 
between blades within the MSC-S BC must be not configured. 

RNC DT DEFINTION IN MSC-S BLADE CLUSTER 

Follow the DT to define the RNC node in the MSC-S BC. 

The SUA signaling is shown below in the MSC Blades. In the TSC 
Blades there is no signaling definition regarding RNC. Only 
dummy routes. 

The SPX nodes are responsible to establish the signaling 
connection towards RNC, i.e. the SCTP associations, M3UA 
routing tables and so on. The signaling transport is described in 
more details in the Signaling in MSC-S BC chapter. 
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Common DT for all MSC Blades: 
■ Signaling Definition 

UANPI:SP=2-3101 ,ASSP=2-3300; 
UANPC:SP=2-3101 ,SPIDNT=RNC3101 ; 
UANSI:SP=2-3101 ,SSN=142; 


■ Route Definition 

EXROI:R=RNC1o&RNC1 i, DETY=MUIUCM, SI=SCCP, SP=2-3101, FNC=3; 
EXRBC:R=RNC1i, RGSPAR=MGG-MGWG3; 

EXRBC:R=RNC1o, RGSPAR=MGG-MGWG3; 

Figure 6-25: RNC Signaling and Route Definition 

Not all the SUA signaling definition is show here as it was defined 
in the Signaling Chapter. For more information check the Signaling 
chapter for ASP, SGP definitions. 

RNC Signaling in the SPX nodes: 

■ Destination Point code (RNC): 

C7SPI:SP=2-3101 ,OWNSP=<ownsp>,NET=IP; 

C7PNC:SP=2-31 01 ,SPID=RNC1 ; 

■ Cooperating SP in the SCCP level: 

C7NPI:SP=2-3101 ; 

■ Hosted Point Code Connection required: 

C7NPC:SP=2-3101 , MSG=1, MTC=1, HPCCON; Howards RNC! 
C7HPI:SP=2-3300; Howards MSC Blades! 

■ M3UA Routing Table: 

M3RSI:DEST=2-3101 ,SAID=ERAMGW3101 ,PRIO=1 ,BMODE=PEER; 
M3RAI:DEST=2-31 01 ,SAID=ERAMGW31 01 ; 


Figure 6-26: RNC Signaling and Route Definition (cont.) 
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Common DT for all MSC Blades: 

■ LAI Definition 

MGLAI:LAI=240-99-3101; 

MG LAC :LAI=240-99-31 01 , PFC=ON; 

■ RNC Definition 

MGRII:RNC=RNC3101, RNCID=240-99-31 01 , R1=RNC1o, R2=RNC1i; 

■ Paging Area: 

MGMAI:RNC=RNC31 01 ,LAI=240-99-31 01 ; 

Figure 6-27: RNC Location and Paging Area 


Common DT for all MSC Blades: 

■ Area Cluster Definition: 

MGAAI:AREA=31 01 A, SAI=240-99-31 01 -01 ; 

MGAAI:AREA=31 01 B, SAI=240-99-31 01 -02; 

MGAAI:AREA=31 01 C, SAI=240-99-31 01 -03; 

MGAAC:AREA=3101A,RO=1, CO=5, EO=1; 

MGAAC:AREA=31 01 B,RO=1 , CO=5, EO=1 ; 

MGAAC:AREA=3101C,RO=1, CO=5, EO=1 ; 

a RNC Location Number: 

MGLCI :AREA=31 01 A, LOCNO=4-491 723101; 

■ Outer RNC Initiate: 

MGORI:RNC=RNC6101, RNCID=240-99-6101 , MSC=MSC4; 
MGORI:RNC=RNC6102, RNCID=240-99-6102, MSC=MSC4; 
MGORI:RNC=RNC9101, RNCID=240-99-9101 , MSC=MSC5; 

Figure 6-28: RNC Area Cluster and Location Number 

First, a route must be defined for cell analysis from the MSC to the 
RNC, the Device Type (DETY) is MUIUCM and the Service 
Indicator (SI) is SCCR 

MGRII is used to connect the incoming and outgoing traffic routes 
to the RNC, RNCID means the RNC Identity which is composed of 
Mobile Country Code (MCC), Mobile Network Code (MNC) and 
RNC number (RNCNO). Rl, R2 are the outgoing and incoming 
traffic route associated with the RNC. 

Then, the definition and the connection of a location area in the 
MSC are supposed to be done by using MGLAI. 
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MGMAI is used to define a connection between a LAI and a RNC. 
This connection is needed for paging purposes (It defines a paging 
area). 

Then, an area cluster has to be defined with MGAAI. An area 
cluster can have one or more SAIs, LAIs or PLMNs connected to 
it. Data such as RO, CO, EA can be connected to an area cluster 
with MGAAC. 

It can be assigned a location number to a specific area cluster by 
using the command MGLCI. 

The outer RNC represents the neighbors’ access nodes. They are 
defined using the command MGORI. Also the MGNMI and 
MGCVI to define the MSC which controls the correspondent RNC 
is defined previously. 
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APPENDIX 

ASYNCHRONOUS TRANSFER MODE (ATM) 

The WCDMA network must be able to offer today’s range of 
services as well as services with new features, for example high bit 
rates (more than 2 Mbps). The requirements of modern networking 
involve 

• Handling multiple types of traffic. 

• Reliability and flexibility of the communications links. 

Voice, video and data traffic all have individual characteristics. 
These multiple types of traffic make very different demands on the 
communications channel and these demands can sometimes be 
completely opposed to each other. The biggest problem is that 
transmissions occur at statistically random intervals. 

If we want to combine data, voice and video on the same links, the 
solution is to use ATM with fixed and relatively short packets so 
that the delays produced by each packet is short and probably 
fixed. ATM is a transmission technology that uses fixed-size 
packets called cells. A cell is a 53 bytes packet with 5 bytes of 
header/ descriptor and 48 bytes of payload, or user traffic - voice, 
data, or video. 

In the WCDMA, ATM links are used between RBS and RNC, and 
between MSC Server and RNC. 


THE ATM CELL 


ATM is a packet mode technique, but the delay in the network can 
be kept to a minimum because the cells have a fixed length. The 
format of an ATM cell is described in Figure 6-4. 
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Error control of the header 



Figure 6-29: Format of the ATM cell 

The most important field in cell header is the address field. It 
identifies the circuit and provides a unique link address between 
two network nodes in the form of a logical channel number (LCN). 

The logical channel number is identified by: 

• The Virtual Path Identifier (VPI, 8 or 12 bits). 

• The Virtual Channel Identifier (VCI, 16 bits). 

The header also contains, as shown in Figure 6-5, 

• Header Error Control (HEC, 8 bits). 

• Payload Type Identifier (PTI, 3 bits). 

• Cell Loss Priority (CLP, 1 bit). 



Figure 6-30: The Contents of an A TM Cell Header 
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THE PRINCIPLE OF ATM SWITCHING 

In an ATM switch, ATM cells are transported from an incoming 
logical channel to one or more outgoing logical channels. A logical 
channel is indicated by a combination of two identities: 

1 . The identity of the physical link 

2. The identity of the channel on the physical link. The identity of 
the channel is made up of the Virtual Path Identifier (VPI) and 
the Virtual Channel Identifier (VCI) 

The switching of cells through an ATM node requires a relation 
between the identities of incoming and outgoing logical channels 
on the physical links between nodes. In Figure 6-6 the principle of 
ATM switching is shown. The values in the cell header specify the 
logical channel number (VPI and VCI). In this example the routing 
table is set up so that incoming ATM cells on link 1, VPI=1, 
VCI=33 are switched to link 3, VPI=1, VCI=125. 


Link in 

VPI 

VCI 

Link out 

VPI 

VCI 

1 

1 

33 

3 

1 

125 

1 

1 

124 

3 

1 

126 

2 

5 

226 

3 

1 

127 



ATM switch 


I 



Link=3 

VPI=1 

VCI=125 

VCI=126 

VCI=127 


Figure 6-31: The Principle of ATM Switching 
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CLASSIFICATION OF SERVICES 


The ITU-T has standardized a protocol reference model for ATM, 
which shows similarities with the OSI model. The three lowest 
layers in the protocol reference model are: 

• Layer 1 - the physical layer. 

• Layer 2 - the ATM layer. 

• Layer 3 - the AAL layer. 

To enable transfer of both data and isochronous services (delay 
sensitive like speech), the information must be adapted to the 
network in different ways. ATM has been divided into four service 
classes (A, B, C and D) on the basis of three parameters. Four 
protocols (AAL 1, AAL 2, AAL 3/4 and AAL 5) are defined for 
each one of the classes. See Figure 6-7. 


Service class 


Class A 

Class B 

Class C 

Class D 

AAL type 


AAL1 

AAL2 

AAL3/4 

AAL5 

AAL3/4 

AAL5 

Service type 


Isochronous 

Asynchro nous 

Bit rate 


Constant 

Variable 

Examples 


Telephony 

Video 
3G mobile 

Connection 
oriented (FR) 

Connection 
less (IP) 


Figure 6-32: ATM Adaptation Layers & Classes 


In the WCDMA, we use AAL2 for speech traffic between the 
MSC/MGW and RNC in Monolithic Architecture and we use 
AAL2 for speech traffic between the MSC Server and RNC in 
Layered Architecture. We use AAL5 for data traffic between the 
SGSN and RNC. We also use AAL5 for signaling between the 


MSC Server/SGSN and RNC. 
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ATM LINK INTERFACE ENHANCED (ALI-E) 


The ATM Link Interface Enhanced (ALI-E) is an interface for ATM 
inter-working in AXE nodes. ALI-E gives ATM termination 
capabilities in AXE for both user plane and control plane offering 
combined, reliable, and powerful signaling terminal and exchange 
terminal functions. ALI-E is based on GEM (Generic Ericsson 
Magazine) mechanics and includes support for RPB-E (Ethernet 
based) communication with CP. That represents an enhancement of 
previous version of ATM termination based on GDM mechanics 
(ALI), giving better performances in terms of traffic and signaling 
capacity. 

ALI-E operates at 155 Mbit/s and terminates STM-l/VC-4 (or 
STS-3c/SPE), ATM/AAL2 and ATM/SAAL. 

ALI-E has a hardware implementation consisting of a single board 
Plug In Unit (PIU) compatible to the GEM. 

The board implements the ALI-E functionality: 

• SDH/SONET termination 

• ATM layer termination 

• AAL2 & AAL5 functions, housed on FPGA 

• RP_ALI block including: 

1. DL34 interface and RPB-S bridge 

2. System controller 

3. Processor (PowerPC750FX) 

4. Ethernet interfaces 

• POWER block 

• CLOCK synchronization and distribution block 

The ALI-E Plug-In-Unit is shown in the following figure. 
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Figure 6-33: ALI-E Plug-ln-Unit 



MAIN FEATURES 


• Termination of STM-l/VC-4 or STS-3c/SPE (optical interface). 

• Termination of ATM/AAL2, maximum 2048 AAL2 channels. 

The traffic types carried over AAL2 can be: 

5. Speech, AMR Coded 

6. Speech, PCM 64 kbit/s Coded 

7. Audio (voiceband data, 28.8, 33.6 kbit/s) 

8. Not bit transparent Circuit Switched Data (Unrestricted 
Digital Information, 14.4, 28.8, 57.6 kbit/s) 

9. Bit Transparent Circuit Switched Data (support of 
multimedia, 64 kbit/s) 

Different traffic types can be freely distributed within the 
maximum capacity limit of 2048 AAL2 channels. 

CBR service category. 

Up to 16 VCC for AAL2 channels. 


• Termination of ATM/ AAL5/SAAL. 
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The maximum total bandwidth for SAAL signaling at ATM 
interface is 9Mbit/s for each direction when used as signaling 
terminal only. The maximum total bandwidth is 6Mbit/s when 
used both as exchange terminal and as signaling terminal. 
Limitations in case of use of RPB-S instead of RPB-E for RP- 
CP communication shall be taken into account. 

nrt-VBR service category. 

Up to 64 VCC for AAL5 channels. 

INTERFACE OFALI-E 

ALI-E has one STM-l/OC-3 interface for connection to an external 
network. 

It is connected to the group switch of AXE by means of the 
proprietary DL34 interface, when used as GS-connected. ALI-E 
can be used together with BYB 501 AXE group switches, 
GS10/GS12 and GS890. In case connection to GS 10/12 GS is 
required, NNRP5 for DL3/DL34 adaptation is required. 

ALI-E is connected to the central processor either with duplicated 
Serial RP interface or via duplicated Ethernet based RP bus 
interface. 



Figure 6-34: Interface of ALI-E 


SOFTWARE ARCHITECTURE 

The software for ALI-E is structured with functional blocks as 
shown in Figure 6-10. 

The blocks can be divided in categories as follows: 

• Command blocks handling the interface towards the operator. 

• Application blocks such as SDIPST2, ATMH2, AAL2H2 and 
SAALH for administration and maintenance. 

• A hardware owning block, ETATM2. 
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• A devices owner block, ETADEV2. 

• A hardware driver block, ATMHWD2. 

• Interface block such as A AH towards Bearer Control (not 
belonging to ALI-E CRT). 

ALI-E HANDLING OBJECTS 


The Handling Objects of ALI-E are as shown in the following 
picture: 



The Switching Network Terminal (SNT) represents the ALI-E 
equipment. 

The Extension Modules (EM) are administered by APZ and mainly 
used for addressing of the HW. 

Each STM-l/OC-3 interface is addressed using the Synchronous 
Digital Path, SDIP-, object. One SDIP corresponds to one STM- 
l/OC-3 interface and is given a unique name in the AXE network 
element. The different layers of the SDH termination (MS, VC- 
4/SPE) are all addressed using the SDIP name by using an index. 

The ATM port addresses the ATM layer and is the entity seen by 
the upper layers in ALI (AAL layers) and outside ALI-E. There is 
one ATM port for each ALI-E unit. 
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Up to 8 Virtual Paths (VP) can be defined for each ATM port. Up to 
80 Virtual Channels (VC) can be connected to the VP A maximum 
of 16 VCs can be defined for AAL2. A maximum of 64 VCs can be 
defined for AAL5. 

ALI-E CONFIGURATION TYPES 

ALI-E can be configured either as GS-connected or as GS-less if 
used as signaling terminal only. ALI-E GS-less does not require a 
connection to the GS. Note that ALI-E GS-less and GS-connected 
cannot coexist on same node, i.e. all ALIs shall be configured 
either GS-less or GS-connected. 

GS-less ALI GS-connected ALI 




Figure 6-36. ALI-E Configuration Types. 

The signaling information is transferred to the central processor via 
the RP bus where the upper layers of the CCS7 protocol (MTP3 
and higher) are processed. 

A total number of 64 AAL5 channels are supported. Each AAL5 
channel is transported on a Permanent Virtual Circuit (PVC). The 
ALI can handle up to 8 Virtual Paths. 

The AXE parameter ALIST indicates if the ATM Link Interface 
configuration is GS-connected or GS-less. By default the GS is 
connected. 
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7 Location Updating 


Objectives 




Explore MSC-S BC and HLR communication during 
Location update process. 

* Write the MML for the SCCP and SUA communication 
between MSC-S BC to HLR by interpreting the exchange 
requirements. 

■ Define the MML for roaming agreements by interpreting the 
exchange requirements. 




Figure 7-1. Objectives 
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INTRODUCTION 

In this chapter we will consider the Data Transcript enabling 
communication between VLR and HLR (and vice versa). 

VLR communicates with HLR, when MS/UE initially connects to 
the MSC/VLR Service Area; this is called a Location Update. VLR 
may also need to communicate with HLR for other reasons, for 
example requesting new authentication vectors (triples or quintets) 
or changing supplementary service information. 

HLR communicates with VLR as a response to a request from VLR 
or if VLR needs to be updated. VLR may need to be updated if 
there are operator changes, in the HLR, to the MSs/UEs 
supplementary services. 

To support Location Updating a small amount of Data Transcript is 
required, namely: 

• IMSI Number Series Analysis 

• SCCP Global Title Analysis 

• Global Title Routing Case Analysis 

All other SCCP communication requires only: 

• SCCP Global Title Analysis. 

• Global Title Routing Case Analysis. 
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LOCATION UPDATING 


Figure 7-2 shows how a Location Update takes place. 



IMSI to MGT 


Figure 7-2: Location Updating 

The following sequence of events occurs. 

1. MS/UE is powered on and it realizes that it is currently located 
in a new location area. The MS/UE then sends a Location 
Update Request message up to MSC-S Blade Cluster/VLR. The 
message contains the IMSI of the MS/UE. The Location 
Update Request is a message from the DTAP protocol and 
requires SCCP to carry the message from BSC/RNC to MSC-S 
BC/VLR. Some SCCP definition is required. 

2. In this example the MS/UE has powered on. However, the 
MSC-S BC/VLR does not recognize the IMSI of the MS/UE 
and has no information about the subscription. Therefore, 
MSC-S BC/VLR must request subscriber data from HLR, 
where the MS/UE subscription is currently located. For this to 
take place the IMSI must be converted to a Mobile Global Title 
(MGT) and also determine the MAP version to be used 
between MSC-S BC/VLR and HLR. All of this information is 
determined from the IMSI Number Series Analysis. 
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3. The Update Location MAP message is sent from MSC-S BC 
/VLR to HLR using SCCP, and, if necessary, MTP is also used. 
Some SCCP definition is required for this to take place, both in 
MSC-S BC/VLR, HLR and the other MSC-Servers in the 
PLMN. 

4. The HLR will send back the Insert Subscriber Data (ISD) MAP 
message. Again SCCP/MTP will be used to transport the MAP 
message between the HLR and MSC Server/VLR. SCCP data 
will need to be inserted to allow the MAP message to be 
terminated in MSC-S BC/VLR. 

Note: If there is a Gs interface between MSC Server and SGSN, 
then the Location Updating and Routing Updating can be 
combined in one message. However, if there is no Gs interface, the 
two updating procedures will be independent of one another, thus 
causing an increase in the amount of signaling taking place. 

The translation between SCCP and SUA inside the MSC-S BC will 
be explained later on. 
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COMPARISON OF THE OSI REFERENCE MODEL TO THE 
CCITT NO. 7 MODEL 

Comparisons between the CCITT No. 7 and OSI model will be 
considered. 

MESSAGE TRANSFER PART 


CCITT No. 7 


OSI 



Figure 7-3: SS7 and OSI Model 


Figure 7-3 shows that the two models do not exactly align with 
each other, that is, MTP does not fully meet the requirements of the 
three lower layers of the OSI model. 

The first C7 signaling system was developed to carry messages 
between telephone exchanges for setting up telephone calls in the 
PSTN. The message is related to the telephone call and is circuit 
related. 

However, the OSI model describes two services at the Network 
level, Connection-Orientated service and a Connectionless 
service. A connection-orientated service allows the exchange of 
data (set-up, data transfer, and disconnection) between two 
systems. The connectionless service is a faster way of transmitting 
small amounts of data. MTP only supports a connectionless 
service. 
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SIGNALING CONNECTION CONTROL PART (SCCP) 

It can be seen from Figure 7-4, that SCCP is connected above MTP. 
In the previous section it was stated that the three lower layers of 
the OSI Model supports a connection-orientated service and a 
connectionless service. With the addition of SCCP, the 
requirements of layer 3 (network layer) of the OSI reference model 
are met. 


CCITT No.7 


OSI 



Figure 7-4: Signaling Connection Control Part SCCP 


Connectionless Service 

The connectionless service transfers a single packet of information 
at a time between two systems. Each packet will contain some 
routing information. If the amount of data to be transferred is 
greater than one packet, the information must be split between 
several different packets. Each packet will contain routing 
information. The SIF (Signaling Information Field) in the MSU 
(Message Signaling Unit) has a maximum size of 272 octets. The 
SIF is made up of the data + the MTP label. 

The service is typically used for the transfer of small amounts of 
real-time critical information, for example, signaling within the 
mobile network. 
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Connection Orientated Service 

In the connection-orientated service, a logical connection is 
established between two SCCP nodes by an initial message. The 
initial message will also contain routing information. The following 
messages belonging to this connection are given a reference 
number and a DPC. This means less analysis for each message is 
required, thus providing a more efficient method of transferring 
information between two nodes. When the transfer procedure is 
finished the connection is released. 

The Integrated services User Part (ISUP) can use SCCP for end to 
end signaling. 


SCCP Messages 


Figure 7-5 gives a breakdown of the SCCP message. The SCCP 
message is found in the User Information part of the Message 
Signal Unit (MSU). The rest of the User Information would contain 
TCAP and MAP information. 


GT 

SSN 

SPC 

Rl 

GT 

SSN 

DPC 

46812345 

VLR 

2-100 

GT 

46854321 

HLR 

2-101 

Calling party address 

Called party address (Address Indicator) 



USER INFO 



' DPC 

Nl 

SI 

SCCP Message 

9 

100 

101 

2 

SCCP 


MTP - 
message 
(MSU) 


Figure 7-5: Structure of the SCCP Message 

The definition of the information contained in the message is given 
below. 
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Global Title (GT) 

A Global Title (GT) is the address of a node. This unique number is 
used to signify where the message originated from (referred to as 
the ‘Calling Party Address’) and also the destination of the message 
(referred to as the ‘Called Party Address’). The GT has a 
numbering format based on a dialed number; a number like an 
MSISDN based on the E.164 series. 

The GT is made up of four components, Address Information AI, 
Nature of Address NA, Numbering Plan NP and the Translation 
type TT. The allowed values are shown below. 

AI is the numerical address of the node and is based on the E.164 
series. Both national and international formats are allowed. 

NA defines whether the address information is in the national or 
international format. 

NA=3, National 

NA=4, International 

NP defines the numbering plan of the address information. 

NP=1, Number series based on the E.164 numbering plan. 

NP=7, Number series based on the E.214 numbering plan. 

TT is the Translation Type. 

TT=0, is the GSM network. 

TT= 1-254, is used to communicate with special nodes like the 
SMS-SC. The value is set by exchange property. 

Point Code 


DPC is the Destination Point Code and is the destination of the 
message on the MTP level. SPC is the Signaling Point Code where 
the message originated. 
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Subsystem Number (SSN) 

The Subsystem Number (SSN) is an address, which identifies the 
owner or receiver of the message, that is, the user of SCCP. Some 
examples of the values of SSN are as follows: 

• HLR: SSN=6 

• VLR: SSN=7 

• MSC/GMSC: SSN=8 

• EIR: SSN=9 

• AUC: SSN=10 

• SC: SSN=12 

• RNC: SSN=142 

• FNR: SSN=253 

• BSC (ANSI): SSN=222 

• BSC (ETSI): SSN=254 


Routing Indicator (Rl) 

The Routing Indicator (RI) is used to determine how the SCCP 
message should be routed, either based on the GT and SSN, or 
DPC and SSN. 

This parameter is used for ANSI only. 

Routing of SCCP Messages 

The routing of SCCP messages uses either the GT and SSN or the 
DPC and SSN. Below are examples of a network with the 
commands showing both types of routing. 
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Routing on the GT 

The Data Transcript shown in Figure 7-6 relates to node A. 



SP=2-101 


Figure 7-6: Routing of the SCCP Message Using the GT 


Node A has an SCCP message that needs to be sent to node C. 
From the example it can be seen that the GT of node A is 46812345 
and that the GT in node C begins with 491.... The two nodes 
concerned belong to different networks and different countries; 46 
is the country code for Sweden, 49 is the country code for 
Germany. 


Since node A does not know the full SPC of node C, node A is 
unable to give the ultimate destination of the SCCP message. 


The SCCP message is routed using the GT from node A to node B. 
Node B must then analyze the GT and then route the message to 
the MTP network and then onto node C. In this example node B is 
classed as an intermediate SCCP node. 


Data Transcript Definitions 

C7RSI 


C7RSI is a C7 MTP command specifying the routing of the 
signaling traffic. Messages with NI=2 and DPC=101 are sent out 
on Link Set 2-101. (More C7 MTP commands are needed to make 
a complete MTP definition.) 

This command is only used now in the SPX nodes as they are the 
unique part of the Blade Cluster with TDM interface (optionally). 
In the MSC or TSC blades this command is not applicable 
anymore. 
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C7NPI - cooperating SCCP node 

The command C7NPI specifies the cooperating SPs known to the 
SCCP. That is to say, only cooperating SPs that contain SCCP 
functionality can be defined using this command. The SP must also 
have been defined previously in MTP. 

The CON parameter tells SCCP that the SP status management 
shall be used for the specified SP. The SCCP management function 
maintains a list of which SCCP SPs are available. The list is based 
on SCCP management messages, which are sent between SCCP 
nodes. If a particular SP is not available, traffic can be stopped, 
queued, re-routed and so on, depending on the network structure. 

This command is only used now in the SPX nodes as they receive 
the signaling from external nodes. Then, the signaling messages are 
translate from SCCP to SUA protocol internally. 

C7NSI - SSN available at SCCP node 


C7NSI defines known subsystems existing in the cooperating SP’s 
node. The management function also keeps a list of the availability 
of known subsystems for each SP. All the SSNs of the cooperating 
SP nodes defined with C7GCI must also be defined with C7NSI. 

This command is only used in the SPX nodes in case SUA 
Associated signaling mode is used. Otherwise is not needed. 

C7GCI - Global Title Routing Case 

C7GCI defines the Global Title Routing Case (GTRC) and the 
Primary Signaling Point (PSP). The PSP is the first choice SP to 
which the signaling traffic is to be directed (see C7RSI). PINTER 
states that the GT of the signaling traffic routed to this GTRC shall 
be analyzed further in the PSP (next SCCP node), that is, routing 
on GT and SSN. 

In node B the signaling messages will be received in SCCP from 
MTP, the GT will be analyzed further and the analysis will lead to 
further routing. 

As global title is analyzed only by MSC blades, neither SPX nodes 
nor TSC blades need to define it. 
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C7GSI - Global Title Analysis 

C7GSI is the analysis of the GT. It has an operating and non- 
operating side. Changes are made to the non-operating side and, 
then, the sides are switched. The main commands to use are 
C7TZI, C7TCI, C7GSI, C7TAI, C7TAR, and C7GSP. 

The GT consists of the address (NS), the numbering plan (NP) and 
the number format called nature of address (NA). TT stands for 
Translation Type, and can be compared to an origin for analysis. 

TT is sent in the SCCP signaling message. 

• NP=1 means MSISDN numbering plan (used in PLMN and 
ISDN). 

• NA=4 means international number format. 

The GT analysis result is a GTRC. 

In Figure below the NS states only the three most significant digits 
of the Global Title. This is all that node A needs to analyze in order 
to decide how to route the signaling message. Nodes close to node 
C will analyze more digits of the GT if required. 

Finally the signaling will reach node C where the analysis is 
terminated on the complete GT. This is not shown in figure but will 
be discussed later. 

Routing on GT will usually be chosen if the next SCCP node is not 
the terminating node. This will be true for most cases. 

Routing on the DPC + SSN 

There are now two examples of routing the SCCP message using 
the DPC and SSN. Example 1 shows only two nodes, while 
example 2 shows a third node not containing the SCCP 
functionality. 

SCCP messages can be routed on MTP-level through nodes that do 
not contain SCCP functionality or through nodes where the SCCP 
functionality should not be used for the particular traffic case. 
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Example 1 



Figure 7-7: Example 1 Routing the SCCP Message on the DPC + SSN 

Data Transcript Definitions 

C7GCI 

In the C7GCI command, the PTERM parameter states that the 
signaling traffic routed to this GTRC shall be terminated in the PSP 
(next SCCP node), that is, routing on DPC + SSN. 

Note: No GT analysis is required in node B. The message is 
terminated and distributed to the SSN. 

C7GSI 


The GT analysis result is a GTRC. 


Example 2 



SP=2-200 

Figure 7-8: Example 2 Routing of SCCP Message on DPC + SSN 
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Data Transcript Definitions: 

C7RSI 


Messages with NI=2 and DPC=101 are sent out on Link Set 2-200. 
In node C the MTP message will be routed further to node B on the 
MTP level. 

C7GCI 


In the C7GCI command, the PTERM parameter is used, since the 
next SCCP node is the terminating node. PINTER would have been 
used if node B had routed the message further. 

Note: Routing on the MTP level can be chosen even when routing 
via SCCP nodes. The advantage is that the load will be lower in the 
intermediate node since less analysis will be required. The 
disadvantage is that the SCCP management functions are not used. 
The SCCP has more advanced functions for handling congestion 
and so on, which is useful in complex networks with many routing 
alternatives. 

Terminating SCCP Messages 


!*** SCCP ***! 

C7GCI : GTRC=1 , PSP=OWNSP; ! GTRC ANALYSIS ! 

C7GSI : TT=0, NP=1, NA=4, NS=46812345, GTRC=1; !* GT ANALYSIS *! 


, /_ 

Node A 

SCOT 
| MTP 

Figure 7-9: Termination of the SCCP Message ITU-T 


GT=46812345 

SP=2-100 


Termination of SCCP messages in the own exchange is performed 
using the OWNSP parameter. This terminates the signaling traffic 
between subsystems in the own node. This line of data is also used 
to terminate signaling traffic received from other nodes with RI set 
to routing on GT. 
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Transaction Capabilities Application Part (TCAP) 

The Transaction Capability Application Part (TCAP) is the 
interface for the Mobile Application Part and other Application 
Parts to access SCCP 

The Transaction Capabilities Application Part: 

• Is a general protocol which makes it easy to introduce new 
features in the telecommunication network, reducing the need 
for development of new protocols whenever new features are 
introduced. 

• Defines an end-to-end protocol between TC-users. 

• Performs common functions like sending/receiving, 
coding/decoding and packing/unpacking of information to/from 
MAP. 

• Distributes messages between function blocks. 

• Gives each transaction a unique identity, which implies that 
each TC-user may have several dialogs running at the same 
time and that there may be several TC-users at the same node. 

• Provides only services based on connectionless network 
services. 

• Is used by MAP. 

• Is coded according to the Abstract Syntax Notation. 1 (ASN.l). 

TCAP makes use of the dynamic buffers offered by the APZ 
function block LAD. The 256wl6 buffers are used and have a 
SAE=348. Two commands are used towards TCAP, C7BPC and 
C7BPP. 

MOBILE APPLICATION PART (MAP) 

The Mobile Application Part (MAP) 

• Provides the necessary signaling procedures required for transferring 
of information between GSM and WCDMA networking entities. 

• Is situated above TCAP, and together they form layer 7 (Application) 
of the OSI model. 

• Handles the necessary signaling for MSC, MSC-S, GMSC, VLR, 
FNR, HLR, AUC, SMS-GMSC, and SMS-IWMSC. 

• Have functions like, for example: Update Location, Roaming Number 
Provision, Insert/Delete Subscriber Data, and Prepare Handover. 
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• Exists in three versions, MAP version 1, MAP version 2 and MAP 
Version 3. Some MAP versions comprise extended signaling capacity, 
which is a requirement for some functions. 

• Uses connectionless signaling provided by TCAP. 

BASE STATION SYSTEM APPLICATION PART (BSSAP) 

The BSSAP is used for communication over the A-interface (MSC- 
BSC) via SCCP and makes use of both the connectionless and 
connection-orientated services offered by SCCP 

BSSAP has two sets of signaling protocols. One handles the 
signaling for the BSS management (BSSMAP) and the other 
handles the Direct Transfer Application Part (DTAP) signaling 
between the MS and the MSC. 

RADIO ACCESS NETWORK APPLICATION PART (RANAP) 

A WCDMA systems protocol that provides necessary signaling 
functions for the communication between the Mobile Services 
Switching Center (MSC) and the Radio Network Controller 
(RNC). RANAP also transfers NAS messages. RANAP is for the 
control information between MSC and RNC whilst NAS is for 
access signaling between MSC and UE. 
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IMSI NUMBER SERIES ANALYSIS 

When the MS powers on in an MSC-S BC/VLR service area, the 
MS must carry out a Location Update. If the IMSI is not 
recognized in the VLR, the VLR must request subscriber 
information from the HLR where the MS subscription is held. 
Remember, when a new subscription is taken out, the subscription 
belongs to one HLR and the MS becomes a visitor whenever it is 
powered on in the MSC/VLR service area. 

The VLR must communicate with the HLR using the MAP signal, 
Update Location. Any MAP signaling uses SCCP and the SCCP 
nodes are addressed using a Global Title. A GT is the same format 
as a dialed number, as it is based on the E.164 series. 

The MS has only sent the IMSI (up to the MSC/VLR) which is 
based on the E.212 series. This is not a dialed number in the 
telephony network. For the VLR to communicate with the HLR, 
the IMSI must be modified to a format allowing it to be used in the 
SCCP network. This new number series is referred to as a Mobile 
Global Title (MGT) and is based on the E.214 series, made up of 
the CC + NDC + MSIN. The CC identifies the country code, NDC 
identifies the network and MSIN identifies the subscriber. 

Note; The MGT is only used for Location Updating. 

This MGT is then used to route the MAP signal through the SCCP 
network from a VLR to the subscriber’s HLR. 

In case of MSC-S Blade Cluster, the SCCP signaling passes 
through SPX nodes and then reach the MSC Blades where the GT 
or SSN is finally analyzed. 

Whenever a new roaming agreement is taken out, the information 
on how to convert the IMSI to a MGT must be specified in each 
MSC/VLR; this needs to be specified even for the PLMN’s own 
subscribers. This translation is referred to as the IMSI Number 
Series Analysis. 

The IMSI Number Series Analysis also gives information on what 
the MS is allowed to do within the current PLMN. This can differ 
from one roaming agreement to another. 
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Figure below shows the command MGISI and some of the 
parameters required for specifying a new agreement. The M 
parameter is the modification from the IMSI to the MGT. The 
ANRES parameter specifies what an MS with an IMSIS=234 15 is 
allowed to do in the network. The available options within ANRES 
can be found in the AI for Mobile Telephony Data Changeable 
Exchange Adaptation and further information may be found in AI 
for blocks MTBSS and MTACC. 


MGISI: IMSIS= 234 15, 

M= 5-44 385 ! MODIFICATION+MSIN => NS (C7GSJI ! 
NA=4 ! INTERNATIONAL NUMBERPLAN ! 
ANRES = 


OB A- 30, 
BO-32, 
CBA-44 
PLMN-J& 

ERIS-12 


! BO FOR ORIGINATINGCALLS 
! ORIGION FOR FORWARDEDCALLS 
! CALL BARRING FOR U.K SUBS. 

! ANNOUNCEMENT LANG . INDICATION 

! ERICSSON SPECIFIEDSERVICES 
! B0=1 => SPN, Bl=l => I£I 


MAPVER- <1 ! MAP VERSION 

INOPER-2 & ! IN OPERATOR GROUP 


CBAZ-40& ! INTERZONE BARRING 

STALL; ! SUBSCRIBER TYPE ALLOWED 


Figure 7- 1 0. IMSI Number Series Analysis 


With regard to Location Updating, two of the ANRES parameters 
are of interest. They are: 

• ERIS 

• MAPVER 


Both relate to the MAP signaling requirements between the VLR 
and the HLR. ERIS details the services that can be supported 
between the VLR and HLR, whilst MAPVER specifies the MAP 
Version. The value ranges and the meaning of these values are 
given the AI for the owning block of the parameter. For example, 
MAPVER is owned by MMAPVS. 

The IMSI Number Series Analysis Table is made up of an 
operating and a non-operating side; changes are made to the non- 
operating side and then switched. The main commands to use are 
MGIZI, MGICI, MGISI, MGIAI, MGIAR, and MGISP. 

When the Update Location MAP signal is sent, the NP parameter in 
SCCP is set to a default value, NP=7. The GT Analysis must reflect 
this, as shown in Figure below. 
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C7NPI : SP=2-2 , CON; 

C7GCI : GTRC=1 , PSP=2-2, PINTER; 

C7GSI : TT=0, NP=7, NA=4, NS=44, GTRC=1; ! MGT UK Subs! 

C7GSI : TT=0, NP=1, NA=4, NS=44, GTRC=1; ! HLR/VLR UK Subs! 

Figure 7-11: SCCP Data for Location Update 

It is very important to remember that if the GT Analysis data for 
NP=7 does not exist, a location update will not be made. 

The second C7GSI command is used to communicate to the HLR 
on other occasions than at Location Updating, for example 
requesting triplets. 

In practice, these two lines, one with NP=7 (Location Updating) 
and NP=1 (for all other VLR to HLR communication), would be 
required for every roaming agreement that exists. 

If a PLMN has more than one HLR, the number series would need 
to be expanded further so as to uniquely identify the individual 
HLR concerned. 
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DATA TRANSCRIPT 

The following sections contain examples of the Data Transcript for 
the IMSI Number Series Analysis and SCCP to support the 
Location Update traffic case. 

DATA TRANSCRIPT FOR IMSI NUMBER SERIES ANALYSIS 

In the network diagram below is used as a reference for MSC-S 
BC. It will show the IMSI Number Series Analysis Data Transcript 
for the IMSIs belonging to the Home PLMN. 

Note: If roaming agreements are to be supported, additional lines 
of MGISI commands are needed. 



IP1: 10.0.1.50 
IP2: 10.0.1.52 
GT: 55 12 330 00 000 
SP=2-2500 


8 x El’s 



SP=2-2351 



18 x El’s 



SP=2-2352 | MS | : 724 55 23 000 00002 

MSISDN: +55 12 123 00002 



I 

□ 

IMSI: 724 55 33 000 50010 
MSISDN: +55 12 133 50010 



SP=2-2700 


Figure 7-12: Network Diagram 


The DT presented here is divided per blade. 
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MGISI: IMSIS=724 55, 

M=5-55 12 33, ! MODIFICATION + MSIN => NS (C7GSI ) ! 
NA=4 , ! INTERNATIONAL NUMBER PLAN ! 

ANRES= 


OBA-30& 

CBA-63S 

BO-22S 

PLMN-0& 

ERIS-15S 


MAPVER-2& 

NRRG-OS 

OWNMS& 

NATMS& 

CBAZ-40& 

STALL; 


! BO FOR ORIGINATING CALLS ! 

! CALL BARRING FOR LEBANON SUBS . ! 
! BO FOR CALL FORWARD ! 

! ANNOUNCEMENT LANG. INDICATION! 

! ERICSSON SPECIFIED SERVICES ! 

! B0=1 => SPN, Bl=l => ICI, ! 

! B2=l => OIN, B3=l => DMSISDN ! 
IMAP VERSION 3 ! 

! ROAMING RESTRICTION GROUP ! 

! OWN PLMN! 

! NATIONAL PLMN ! 

ICALL BARRING INTER-ZONAL CALLS! 
! SUBSCRIBER TYPE ALLOWED! 


Figure 7-13: IMS I Series Analysis DT All MSC Blades 

In Figure 7-13 all IMSI numbers starting with the digits 724 55 are 
being converted to a MGT of 55 12 33. This is achieved by 
removing the first five digits and replacing them with the digits 55 
12 33 using the parameter M (M=5-55 12 33). The MGT is in the 
international format. 

To support communication between the VLR and the HLR the 
ANRES parameters ‘ERIS’ and ‘MAPVER’ are important. 

• ERIS is used to identify whether the HLR supports the Ericsson 
Proprietary Services: Single Personal Number, Immediate Call 
Itemization, Originating Intelligent Network and Dual 
MSISDN. 

• MAPVER indicates that MAP version 3 is to be used to the 
HLR. 

Some of the other parameters are mandatory parameters but are not 
relevant for Location Updating. However, they will be explained in 
a later module. 

More information can be found also in the AI for Mobile 
Telephony Data Changeable Exchange Adaptation and further 
information may be found in AI for blocks MTBSS and MTACC. 
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DATA TRANSCRIPT 

MTP SCCP and SUA definition 

■ HLR C7 Signaling Point: 

C7SPI:SP=2-2500 ,OWNSP=ownsp; 

C7PNC:SP=2-2500 ,SPID=HLR1; 

(IHADI... IHASC... M3ASC... M3RSI... 

M3RAI... towards HLR) 

■ SCCP Initiate: 

C7NPI:SP=2-2500; 

C7NPC:SP=2-2500 ,MSG=1 ,MTC=1 , HPCCON; 

Figure 7-14: MTP & SCCP Definition In the SPXes 

As SPX nodes are the one visible to the external nodes, the 
destination point and the SCCP cooperation of HLR are defined 
there. 

Notice that the HLR SP needs to be changed using the command 
C7NPC with parameter option HPCCON. That means that this SP 
point is used in the SCCP level and also in the SUA level. 

The parameters MSG and MTC are used to define the SCCP 
message type (such as UDT, UDTS, Extended Unitdata (XUDT) 
and Extended Unitdata Service (XUDTS) messages) and MTC 
(Message type change allowed from XUDT or XUDTS to UDT or 
UDTS, and the opposite is also true, or from LUDT or LUDTS to 
XUDT or XUDTS). 

Here is not showing the complete DT for SIGTRAN, as this is 
detailed in the Signaling in MSC-S BC chapter. So, besides all 
these commands it is also necessary to define all the signaling 
transport. 

User Guide for Message Transfer Part 3 User Adaptation Layer 
(M3UA) is a good reference as well. 
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■ SUA Signaling definition: 

UAASI:ASID=“SMA1000", SPTYPE=SGP, DPC=1000, Nl=2, PROT=SUA, 
RC=1000; 

UAPRI:SPID="3303", PROT=SUA, ASID=" SMA1000 
UAPRI:SPID=' , 3304", PROT=SUA, ASID=" SMA1000 
UAPRI:SPID="3305", PROT=SUA, ASID=" SMA1000 
UAPRI:SPID="3306", PROT=SUA, ASID=" SMA1000 

■ Hosted Point Code (represents MSC-S): 

C7HPI:HPC=2-1000; IMAP! 

Figure 7-15: SUA Definition In the SPXes 

Not all the SUA Signaling is shown here such as the Signaling 
Process (UASPI...) which is defined in the Signaling chapter. 
Please refer to the signaling chapter for more details. 

SUA signaling definition in SPX nodes is using Quasi-Associated 
Mode as a recommended configuration. 

The Adaptation Direction SIGDA: Traffic Data: SUA Network 
Configuration presents both configurations mode. 

In the SPXes should be defined the Application Server process type 
SGP, that means the process responsible to receive the Hosted 
Signaling Point from the external network. The RC parameter is 
mandatory for SGP type. 

Also, the ASP processes are used in order to address the blades in 
the SUA network level. This MSC Blades ASP processes are 
defined in the implementation phase. 

The command C7HPI is used to define the HPC. This HPC is the 
signaling point used by external nodes to deliver the signaling 
information to MAP in the MSC-S BC. This command is valid only 
in SPXs. 
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■ SUA Signaling: 

Definition of ASP for MAP: 

UAASI:ASID="MA1000", SPTYPE=ASP, DPC=1000 Nl=2, PROT=SUA; 

Definition of SGP (represents the SPX nodes): 

UASPI:SPID="SPX1", SPTYPE=SGP, PROT=SUA, SAID=ISUSPX1 , 
SGID=SPX1 ; 

UASPI:SPID="SPX2", SPTYPE=SGP, PROT=SUA, SAID=ISUSPX2, 
SGID=SPX2; 

Relation between ASP and SGP: 

UAPRI:SPID="SPX1 ", PROT=SUA, ASID="MA1000",RC=1000; 
UAPRI:SPID="SPX2", PROT=SUA, ASID="MA1000",RC=1000; 
UAPSC:PROT=SUA, STATE=ACT, SPID=SPX1 ; 

UAPSC:PROT=SUA, STATE=ACT, SPID=SPX2; 

Figure 7- 1 6: SUA Definition All MSC Blades 

SUA definition in the MSC Blades will be exactly the same data 
transcript file. All the MSC Blades should have the ASP and SGP 
processes definition as described above. 

For each application protocol such as MAP, BSSAP, RANAP and 
other needs a correspondent ASP. In the example, the MAP 
protocol is defined as “MA1000”. The NI (Network Indicator) and 
DPC (Destination Point Code) are the signaling point seen by the 
external nodes. In this case the HLR sees the MSC-S BC as SP=2- 
1000 for MAP signaling messages. 

Then, the UAPRI command is used to relate the ASP (application 
protocol) to SGP. The RC=1000 (Routing Context) represents in 
the SGP process the specific ASP. 

Check the explanation regarding RC in the SUA RFC: “An 
Application Server Process may be configured to process traffic 
within more than one Application Server. In this case, the Routing 
Context parameter is exchanged between the SGP and the ASP (or 
between two ASPs), identifying the relevant Application Server. 
From the perspective of an SGP/ASP, the Routing Context 
uniquely identifies the range of traffic associated with a particular 
Application Server, which the ASP is configured to receive. There 
is a 1:1 relationship between a Routing Context value and a 
Routing Key within an AS. Therefore the Routing Context can be 
viewed as an index into an AS Table containing the AS Routing 
Keys”. 

Activate the local node behavior process with the correspondent 
signaling process by using the UAPSC command. 
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Definition of SP in SUA network: 

UANPI:SP=2-2500, ASSP=2-1000; 

UANPC:SP=2-2500, SPIDNT=HLR2500; 

UANSI:SP=2-2500, SSN=6&10; 

Figure 7- 1 7: SUA Definition All MSC Blades (cont.) 

This last part from SUA definition is done regarding destination 
signaling data. Note that the command UANPI is used to define the 
SP from the HLR, as this network the MSC-S BC is connected 
directly to the final node. Also, it is associating the local 
application server process to the SP. 

The command UANSI is setting up the SSN (SCCP Subsystem 
Numbers) which have the same values in the SCCP commands 
(C7NSI). 


■ GT Table definition: 

C7TZI; 

C7TCI; 

C7GCI: GTRC=1, PSP=2-2500, PTERM; IHLR1 ! 

C7GCI: GTRC=2, PSP=OWNSP; 

C7GSI:TT=0, NA=4, NP=1 , NS=551 233, GTRC=1; 

C7GSI:TT=0, NA=3, NP=1 , NS=1233, GTRC=1; 

C7GSI:TT=0, NA=4, NP=7, NS=551 233, GTRC=1 ; !MGT - HLR1 ! 
C7GSI:TT=0, NA=4, NP=1 , NS=551 21 1 , GTRC=2; 

C7GSI:TT=0, NA=3, NP=1 , NS=121 1 , GTRC=2; 

C7TAI; 

C7TAR; 

C7TLI; 

Figure 7-18: Global Title Analysis table All MSC Blades 

The GT analysis in done only in the MSC blades, neither TSC 
blades nor SPX nodes do that. 

C7TZI command is used to zeroing the non-operating table and the 
C7TCI is used to copying all the data in the operating side to the 
non-operating side. This procedure guarantee that all the time the 
table is modified the previous content is there. 

The parameters have been described in the section before. 


Global Title Table definition 
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■ Definition of Own Calling Address: 

MGCAC:INT=55 1 2 1 1 23 40000, NAT=1 2 1 1 23 40000; 

!Own address for MSC/GMSC! 

Figure 7- 1 9: Define the Own Calling Address All MSC Blades 

There is no definition of Calling Address in the TSC Blades either 
SPX nodes. 
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8 Telecommunication Services Analysis 


Objectives 


Outline Telecommunication Service Analysis performance in the MSC-S 
BC according to the system specifications. 

■ Define the TSA for a teleservice (TS) and for a bearer service (BS). 

■ Identify the TMR analysis input and output parameters. 

■ Name the purpose of the Compatibility Check 






Figure 8- 1 . Objectives 
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INTRODUCTION 

The Telecommunication service analysis is mandatory. 

It specifies the telecommunication services available in the 
network, and also the demands on the WCDMA or GSM network 
to support a specific service. It is divided into two parts: one to 
identify the service requested, and one to specify the requirements 
for the connection. It will be performed for both mobile originating 
and mobile terminating calls. 

BEARER CAPABILITIES (BC) 

Within an Integrated Services Digital Network (ISDN), a Public 
Switched Telephony Network (PSTN), and a WCDMA or GSM 
network, a number of different services are available. These 
services include speech, facsimile, and data transmission with 
different user rate (URATEs). The receiving node, as well as 
intermediate nodes, need information on what service is requested 
and how the service is to be performed, for example, what URATE 
is used. 

The basis for determining call type is the Bearer Capability (BC). 

BCs only apply to WCDMA, GSM and ISDN since PSTN cannot 
provide this information. 

Different coding schemes and protocol stacks are used in ISDN and 
WCDMA/GSM because different transmission requirements must 
be met. They are referred to as ISDN BC and WCDMA/GSM BC 
respectively. 

The WCDMA or GSM BC and the ISDN BC are different from 
each other so an incoming ISDN call needs to translate the BC 
while an incoming PSTN call needs to generate a WCDMA BC in 
the WCDMA or a GSM BC in a GSM. 

Bearer Capabilities (BCs) contain this information. BCs are part of 
the User Service Information Element (USIE) in the Initial Address 
Message (IAM), and the Bearer Capability Information Element 
(BCIE) in the SETUP message. 

Note: This only applies to ISDN and GSMAVCDMA, since PSTN 
cannot provide this type of information. 

For an UE originated call, the WCDMA BC is received from the 
UE. 


LZT 123 9083 R1 A 


© Ericsson 2009 


- 195 - 





MSC-S R13.1 Blade Cluster Data Transcript 


ERICSSON ^ 


For an MS originated call, the GSM BC is received from the MS. 
For a call coming from PSTN/ISDN there are 3 possibilities: 

• The incoming route supports ISUP. The ISDN BC is translated 
into a WCDMA/GSM BC in the HLR by software. 

• Only the MSISDN is received. In this case a default BC is 
generated for the call. This default BC setting is generated by 
the subscriber data DBSG (Default Basic Service Group). This 
would be the case for all calls generated in PSTN where ISUP 
is not supported. 

• The third alternative is for calls with no BC requiring support 
of DTI/DTI2 or any other services not supported by the DBSG. 
In this case an additional MSISDN (AMSISDN) is used to 
identify this particular service. 

An exchange in WCDMA or GSM must be able to provide: 

• Translation of ISDN BC to WCDMA/GSM BC and vice-versa 
(HLR). 

• Translation of the requested service into requirements on 
signaling and transmission capabilities. 

• Compatibility check to determine if the required signaling and 
transmission capabilities are fulfilled by the route or equipment 
to be used. 

GSM/WCDMA DATACOM SERVICES 

This feature provides the basic functionality needed for circuit- 
switched data services for speeds of up to 9.6 kbit/s (for GSM) and 
64 kbps (for WCDMA). Data compression is also part of this basic 
feature. 

The feature also provides the basis for the optional features Fax, 
High Speed Datacom Service (for GSM) and Integrated Access 
System (IAS). 

The feature supports connections between WCDMA subscribers 
and subscribers using modems over PSTN or Unrestricted Digital 
Information (UDI) over ISDN. It also supports connections using 
Frame Tunneling Mode (FTM). 

The data services provided by this feature can be used for a 
multitude of applications, some of the most important being WAP, 
Internet access, or remote access to a corporate LAN. 
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Data Transmission Interworking Unit (DTI) platforms 

In order to support data services within GSM/WCDMA networks, a 
GSM/WCDMA Interworking Function (IWF) is needed. The 
Ericsson implementation of this IWF is the DTI (Data 
Transmission Interworking Unit). The DTI exists in two versions, 
DTI and DTI2, of which the DTI2 is the standard product for new 
deliveries. 

The MSC Server will utilize the DTI hardware in a remote Media 
Gateway. 

The DTI/DTI2 is a protocol converter for circuit-switched data 
communication via the MSC which enables mobile data and fax 
users to connect to either ISDN/PSTN services or to the Internet 
via an Integrated Access System (IAS). 

Both Mobile Originated and Mobile Terminated calls are 
supported, as well as Mobile-to-Mobile calls. Combining the two 
first cases does the latter case. 

Bearer Services for GSM and WCDMA 

All services within the GSM network, be it speech, SMS, data or 
fax, are assigned a telecommunication service. This service is 
divided into two categories, Teleservices and Bearer services. 
Bearer services provide the means to transfer speech and data 
information between users. Teleservices provide the complete 
capability, including terminal equipment functions, for 
communication between users according to operator agreed 
protocols. 

Table 9-1 shows the supported Bearer services in the MSC. Some 
datacom terms are explained below. 

Information Transfer Capability (ITC) 

ITC is part of the Bearer Capability (BC). Every call in a 
GSM/WCDMA network involves the exchange of the BC between 
the mobile phone and the network in order to inform the network of 
what services are connected to the call. The ITC capability can be 
“speech”, “fax”, “UDI” or “3.1 kHz”. Unrestricted Digital 
Information (UDI) is used for digital calls over the ISDN, and 3.1 
kHz is used for modem calls. 
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Synchronous/Asynchronous Transmission 

In synchronous mode, blocks of data are transmitted using “sync 
characters” to synchronize transmitter and receiver. This gives 
higher transmission rates, but requires accurate and expensive 
clock circuits. In asynchronous mode, start and stop bits are used 
when transmitting characters. This allows for easier 
synchronization and variable transmission speed, although it is 
slower than synchronous mode. 

Transparent/Non-transparent service 

Transparent service (T) transmits data transparently across a radio 
interface. The transmission speed will be constant, but bit error 
rates might be high. Nontransparent service (NT) uses a Radio 
Link Protocol (RLP) between the mobile phone and the DTI/DTI2, 
thus guaranteeing error-free transmission. The V.42 error correction 
protocol can be used for all modem types, except V.21. 




T 

NT 


V42 Error correction 

^RLP Error correction 

V42 Error correction 




Figure 8-2: Transparent and Non-transparent services in the GSM 
network 
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Bearer 

Service 

Radio 

Access Rate 
(bps) 

Access 

Structure 

information Transfer 
Capability 

QOS Attribute 

Notes 

20 

300 

Async 

UDI or 3.1 kHz 

Tor NT 

3) 

20 

1200 

Async 

UDI or 3.1 kHz 

Tor NT 

3) 

20 

2400 

Async 

UDI or 3.1kHz 

Tor NT 

3) 

20 

4800 

Async 

UDI or 3.1kHz 

Tor NT 

3) 

20 

9600 

Async 

UDI or 3.1kHz 

Tor NT 


20 

14400 

Async 

UDI or 3.1kHz 

Tor NT 

1) 

20 

19200 

Async 

UDI or 3.1 kHz 

Tor NT 

1) 

20 

28800 

Async 

UDI or 3.1kHz 

Tor NT 

1) 

20 

38400 

Async 

UDI or 3.1kHz 

NT 

1)2) 

20 

43200 

Async 

3.1kHz or “FTM” 

NT 

1)2) 4) 

20 

57600 

Async 

3.1kHz or “FTM" 

NT 

1)2) 4) 







30 

1200 

Sync 

UDI or 3.1 kHz 

T 

3) 

30 

2400 

Sync 

UDI or 3.1kHz 

T 

3) 

30 

4800 

Sync 

UDI or 3.1kHz 

T 

3) 

30 

9600 

Sync 

UDI or 3.1kHz 

T 


30 

14400 

Sync 

UDI or 3.1kHz 

T 

1) 

30 

19200 

Sync 

UDI or 3.1kHz 

T 

1) 

30 

28800 

Sync 

UDI or 3.1kHz 

T 

1) 

30 

38400 

Sync 

UDI 

T 

1) 

30 

48000 

Sync 

UDI 

T 

1) 

30 

56000 

Sync 

UDI 

T 

1) 


Table 9-2: Supported User/Access Rates for GSM 

1) Requires the optional feature NF 954 High Speed Datacom 
Service. 

2) 3.1 kHz requires V.90 (implemented in DTK). 

3) The old Bearer Services 21-26 and 31-34 have been removed 
from the 3GPP specifications, and the rates can be reached by 
negotiation according to the specifications. 
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4) FTM gives possibilities of 64 kbps connection on the fixed side 
of the IWF. See session ‘Frame Tunneling Mode’. 

All services within the WCDMA network are assigned a Bearer 
Service that provides the means to transfer speech and data 
information between users. Table 9-3 shows the supported user 
rates. On the radio interface, only the rates 14.4, 28.8 and 57.6 
kbit/s are supported. The feature supports only Non-Transparent 
services and there is therefore no straightforward relation between 
Air Interface User Rate (AIUR) and Fixed Network User Rate 
(FNUR). 


FNUR 

(bps) 

Access 

Structure 

Information 

Transfer 

Capability 

User 

Information 
Layer 1 
Protocol 

QoS 

Attribute 

Note 

9 600 

Asynchronous 

UDI or 
3.1kHz 

UDkV.1 10 

NT 


14 400 

Asynchronous 

UDI or 
3.1kHz 

UDkV.1 10 

NT 


19 200 

Asynchronous 

UDI or 
3.1kHz 

UDkV.1 10 

NT 


28 800 

Asynchronous 

UDI or 
3.1kHz 

UDkV.1 10 

NT 


38 400 

Asynchronous 

UDI or 
3.1kHz 

UDkV.1 10 

NT 

(Note 1) 

56 000 

Asynchronous 

RDI 

X.31 flag 
stuffing 

NT 

(Note 2) 

64 000 

Asynchronous 

UDI 

X.31 flag 
stuffing 

NT 

(Note 2) 

56 000 

Synchronous 

RDI 

Not Applicable 

T 

(Note 3) 

64 000 

Synchronous 

UDI 

Not Applicable 

T 

(Note 3) 


Table 9-3: Supported user rates 


Note 1: The FNUR rate only applies to UDI. For 3.1 kHz, to 

connect with high-speed modems such as V.90, or modem rates 
below 9.6 kbit/s, autobauding is used. FNUR has no meaning in 
this case. 

Note 2: Frame Tunneling Mode, using HDLC framing on the fixed 
network interface. 

Note 3: 64/56 kbps Synchronous Transparent UDI/RDI service are 
used for 3G.324M Multimedia calls, and is part of the optional 
feature NF 956. 
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Some datacom terms in the table that are part of the Bearer 
Capability (BC) are explained below. Every call in a WCDMA 
network involves the exchange of the BC between the mobile 
phone and the network in order to inform the network of what 
services are connected to the call. 

Fixed Network User rate (FNUR) 

The user rate between DTI2 and the fixed network. That is, the rate 
that applies for the connection between the MSC and the terminal 
that is connected to PSTN/ISDN or the Access Serves that is 
connected to Internet. 

The FNUR can be compared to the Air Interface User Rate 
(AIUR), which is the user rate over the air interface. FNUR and 
AIUR can be different for Non-Transparent services since frequent 
re-transmission may be required on the radio interface due to 
varying radio conditions. 

Asynchronous Transmission 

In asynchronous mode, start and stop bits are used when 
transmitting characters. This allows for easier synchronization and 
variable transmission speed, although it is slower than synchronous 
mode. 

Information Transfer Capability (ITC) 

The ITC capability can be “speech”, “UDI”, “RDI” or “3.1 kHz”. 
Unrestricted Digital Information (UDI) is used for digital calls over 
the ISDN or Internet. Restricted Digital Information (RDI) is used 
in networks that utilize ANSI/Bellcore ISDN signaling. 3.1 kHz is 
used for modem calls. 

Non-transparent service (NT) 

Non-transparent service provides error-correction by using the 
Radio Fink Protocol (RFP) between the mobile phone and the 
DTI2, thus guaranteeing error-free transmission. For error 
correction over the fixed network, this can only be done when 
using 3.1 kHz connection. The V.42 error correction protocol can 
be used over all supported modem types. 
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Figure 8-3: Error correction for Non-transparent services in the WCDMA 
network 


Modem services 


The Information Transfer Capability (ITC) in the GSMAVCDMA 
Bearer Capability dictates what type of service will be required for 
the call. The 3.1 kHz ex PLMN refers to data calls that require a 
modem connection over the PSTN. 


Combined 

MSC Server .'Media Gateway 



Digital Data Format 


t 


Analog Data Format 


i 1 

Digital Data Format 


Figure 8-4: 3. 1 kHz call via modem over the PSTN for GSM/WCDMA 

The DTI/DTI2 provides modem functionality in accordance with 
the following ITU-T specifications: 


V.21 

300 bps asynchronous 

V.22 

1200 bps asynchronous/synchronous 

V.22bis 

2400 bps asynchronous/synchronous 

V.32 

9.6 and 4.8 kbps asynchronous/synchronous 

V.34 

2.4 to 33.6 kbps synchronous 
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V.90 Up to 56 kbps asynchronous/synchronous 

All speeds above 9.6 kbits/s require the optional feature High 
Speed Datacom, which includes HSCSD and 14.4 channel coding. 

For asynchronous bearer services all modems are supported. For 
synchronous bearer services, V.22, V.22bis and V.32 are supported; 
additionally V.34 on 9.6 kbps is supported. 

Speeds below 9.6 kbps are negotiated via autobauding. 
Synchronous modems can be used even though the bearer service 
is asynchronous. For instance can the service be asynchronous 
between the mobile and the DTI2, but synchronous from DTK 
over the fixed network. Since the feature supports only Non- 
Transparent services, the rate between air interface and fixed 
network can differ. 


UDI towards ISDN 


This function supports connections between GSM / WCDMA 
subscribers and ISDN subscribers using “Unrestricted Digital 
Information" (UDI) Information Transfer Capability (digital 64 
kbps) or “Restricted Digital Information” (RDI) (56 kbps) in the 
ISDN. The UDI service covers calls using V.110/X.30 rate 
adaptation within the ISDN. 

A call requesting UDI will terminate at an ISDN connection via a 
Terminal Adapter. UDI calls can also be made from mobile to 
mobile because the GSM network is based on ISDN principles. 
Please note that for mobile to mobile and mobile to ISDN calls it is 
also possible to use modems as an alternative to UDI. 

Combined 

MSC Server /Media Gateway 


MSC 

Server 



Digital Data Format 


Figure 8-5: UDI call via ISDN for GSM/WCDMA 

A call requesting UDI/RDI will terminate at an ISDN connection 
via a Terminal Adapter. 
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The UDI/RDI service is also used for connection to Internet. This 
is illustrated in Figure 8-6 where the UDI call is terminated in an 
Access Server. The Access Server can be both external (as in 
Figure 8-6) and integrated with the MSC by using the optional 
Integrated Access System (IAS). 


Data Compression according to the V.42bis standard increases user 
data rates without changing the characteristics of the radio channel. 
It is used for asynchronous, non-transparent bearer services. Data 
compression can also be used together with High Speed Circuit- 
Switched Data and 14.4 kbit/s Data Channel Coding. 

Data compression may be done on the wireless and/or on the 
wireline side. Furthermore V.42bis is capable of compressing data 
in either both or only one of the directions. The V.42bis algorithm 
provides a mechanism to detect if the user data cannot be 
compressed, upon which it changes to transparent mode. When the 
algorithm detects that compression is possible again, it reverts back 
to compressed mode. 

Typical compression ratios achievable are: 

2:1 data transmission (e.g. HTML) 

3:1 text transmission 


Mobile 

Phone 

MSC/DTI 

PSTN/ 

ISDN 

V42bis 



V42bis 


V42bis 



V42bis 






RLP 



RLP 


V42 



V42 






V1 10’ 



V110’ 


Modem 



Modem 











Compressed data 


Compressed data 



*4 ► 


Figure 8-6: Data Compression GSM / WCDMA 


Data Compression 
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Figure 8-7 shows the protocol model for an asynchronous, non- 
transparent data call, with V.42bis data compression on top of V.42 
and RLP error correction layers. VI 10’ is the modified VI 10 frame 
used in GSM/WCDMA. A digital data call (UDI/RDI/FTM) does 
not use V.42 or V.42bis on the fixed side 


Frame Tunneling Mode for GSM 

The Frame Tunneling Mode feature provides synchronous data 
transmission through the DTI/DTI2 without the need for modems 
or VI 10 rate-adaptation. This results in a service that provides 
much faster connection time than modem (connection time for 
FTM is similar to ISDN), in addition to the added advantage of 
high connection speed (64 kbps, compared to maximal 38,4 kbps 
for normal ISDN, and 48 kbps for V.120). 

Frame Tunneling Mode supports PPP and X.75 protocol links 
through the DTI/DTI2. This can be used for Internet connections 
via the Integrated Access System (IAS) or via an ISDN network. It 
is possible to use all the data rates supported on the radio interface 
for Frame Tunneling Mode calls. Frame Tunneling Mode is also 
called HDLC (High-level Data Link Control) encapsulation on 
ISDN. 

Frame Tunneling Mode for WCDMA 

The Frame Tunneling Mode service provides synchronous data 
transmission through the DTK without the need for modems, and it 
replaces V.110 rate- adaptation with HDLC rate adaptation. 
Conventional modem or V.110 data calls are asynchronous, with a 
start and stop bit added to every data byte transferred. Frame 
Tunneling Mode provides synchronous data transmission through 
the DTK, which eliminates the need for start and stop bits. 
Although this in fact does not improve the throughput over the air, 
FTM connects at 64 kbit/s on the fixed network, while V.110 
connects at 38.4 kbit/s, which affects the data transfer considerably. 
FTM also allows connection to equipment that does not support 
V.110. 

Frame Tunneling Mode supports PPP and X.75 protocol links 
through the DTK. This can be used for Internet connections via the 
Integrated Access System (IAS) or via an ISDN network. It is 
possible to use all the data rates supported on the radio interface for 
Frame Tunneling Mode calls. For WCDMA these are 14.4, 28.8 
and 57.6 kbit/s. 
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Frame Tunneling Mode also supports the proprietary feature 
ASHDLC (Async-to-sync HDLC, sometimes also referred to as 
HDLC (High-level Data Link Control) encapsulation on ISDN. The 
ASHDLC service is initiated by a prefix to the B-number instead of 
being signaled by the mobile. When the MSC identifies the prefix, 
it is removed from the called number before the service is invoked. 

3G.324M MULTIMEDIA SUPPORT 

This feature provides the support for sending and receiving circuit- 
switched multimedia for both WCDMA systems and GSM. Circuit- 
switched multimedia is based on the 3G.324M standard, which is a 
3G-variant of H.324, an ITU-T recommendation for low bit-rate 
multimedia communication. 

The following multimedia call cases are supported: 

• Multimedia calls between WCDMA subscribers 

• Multimedia calls between WCDMA and ISDN subscribers 

• Multimedia calls between GSM subscribers 

• Multimedia calls between GSM subscribers and PSTN subscribers 

A mobile subscriber with a 3G.324M terminal can get video, data 
and audio communication with another 3G.324M terminal or with a 
terminal that is compatible with 3G.324M. The other terminal could 
also be a Video Content Server, acting in accordance with the 
3G.324M standard. 

The 3G.324M recommendation includes the multiplexing of 
different bit streams into one bit stream 

For a multimedia call, the BS30 Bearer Service is used, which 
provides guaranteed quality of service for multimedia 
communication. In the case of WCDMA, the bit-transparent 
service is used in combination with Unrestricted Digital 
Information (UDI). Bearer Service 30 in the transparent mode is 
also used for GSM multimedia calls. In this case the capability of 
the call is set to "3.1 kHz audio" which means that the call is 
treated as an analog call using modems for transfer over PSTN. 

The user rate will be 28.8 kbps, using High Speed Circuit Switched 
Data (HSCSD). 
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The example in Figure 8-8 illustrates a multimedia call between 
two W 3G.324 M terminals. The call is using Unrestricted Digital 
Information (64 kbps) as a bearer. The MSC routes the 3G.324 M 
call based on the E-164 number provided by the calling terminal at 
call set-up. The video/audio media negotiation between the 
terminals is transparent to the MSC. In the picture this negotiation 
is therefore shown as a “closed pipe” going through the MSC. 


RNC 


MSC 


MSC 


RNC 


BTS 


. 


□ LJ 


BTS 




SETUP: (64 kbps , Unrestricted Digital Information , E.164 number) 


ANSWER 


[ \ 

r 

Negotiation imvidcin andio.or. data (according. In IXU-.T.H.245X 

Video fe.g. MPEG4/ITU-T H.263) 

>\ 


; 


* 

\ ) 


Data (e.g. still image from digital camera in JPEG format) 



Figure 8-7: WCDMA Multimedia Call 
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TELECOMMUNICATION SERVICE ANALYSIS 

Telecommunication service analysis must be performed at every 
call set-up. 

The telecommunication service analysis DT is only defined in the 
MSC Blades. 

The input to this analysis is the BASC information along with 
additional parameters. 

The incoming parameters are analyzed and the result adapts to and 
configures the system for the selected service, for example, 
establishing a DTI/DTI2 connection for a fax or data call. 

The analysis is composed of two parts: 

1 . Telecommunication Service Analysis. 

2. Telecommunication Service Code Analysis. 


BASC 

CRT 

TRI 

ITC 

PSCVL 

NIRA 

FNUR 

ACC 

URATE 

RSIG 


ITC Information transfer capability 3.1 khz-UDI-Speech 

CRT Channel rate type 

Figure 8-8: Telecommunication Service Analysis Schematic 

The input to this analysis is: (See Figure 8-9). 

• The Basic Service Code (BASC). It is either a Teleservice Code 
(TEC) concerning speech, Short Message Service (SMS), 
facsimile, emergency call, or a Bearer service Group (BEG) 
concerning data call 

• The Information Transfer Capability (ITC) is either AUDIO for 
3.1 khz modem connections, or Restricted Digital Information 
(RDI), or Unrestricted Digital Information (UDI) 
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• Negotiation of Intermediate Rate Allowance (NIRA) indicates 
whether the Negotiation of intermediate rate function is 
allowed or not 

• Required type of SIGnaling (RSIG) indicates any special 
signaling requirements such as ISDN 

• Fixed Network User Rate (FNUR) indicates the user rate 
signaled and transmitted towards the remote user. 

• Provided Speech Coder Version List (PSCVL) contains the 
version list for speech coder selection 

• SERVICE indicates different WCDMA data services (Basic 
data service (BASIC), Bit transparent service (BT), Frame 
Tunneling Mode (FTM) and Multi Media service (MM)). 

• Transparency Indicator (TRI) indicates if a transparent or a 
non-transparent connection. 

Note: No DTISC anymore in Telecom Service Analysis 

The output from the first leg of the analysis (MGTEI) is: 

• Channel Rate and Type (CRT) is expressed as RCR-SCRT 

• TRI (Transparent Indicator). It indicates if transparent or non- 
transparent mode should be used for Bearer Services (BSs). 
Only used for fax and data calls 

• Allowed Speech Coder Version List (ASCVL). The input 
parameter PSCVL defined in the analysis is compared and 
ASCVL is generated. This is only for speech calls. 

• Selected Negotiation of Intermediate Rate Request (SNIRR). 
The NIRA parameter in the input is compared to the PSCVL 
and SNIRR is generated. 

• Fixed Network user rate (FNUR) allows a user rate from 
9.6kbit/s to 64kbit/s depending on the commercial agreement. 

• TeleService communication Code (TSC) 

This parameter is a numeric output from the 
Telecommunication Service Analysis. It serves as an: 

- Input to Telecommunication Service Code Analysis 
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The requested service is supported by the MSC, only if the 
Telecommunication Service Analysis points out a TSC 

- Input to charging. 

It provides the ability to apply different charging methods to 
different call types, for example, a fax call may be more 
expensive than a speech call. TSC is used as a reference in the 
TT-files. 

The output from the Telecommunication Service Analysis is the 

TSC. It is used as a link to the Telecommunication Service Code 

Analysis defined with command MGTCI, and as a branching 

parameter in the Charging analysis. 

The outputs from the second leg of the analysis (MGTCI) is: (See 

Figure 8-9). 

• Wanted type of SIGnaling (WSIG). The defined WSIG in the 
analysis is compared to the RSIG of the input signal and a final 
WSIG is generated 

• Tone Protection Information (TPI). Whether tone sending is 
allowed or not. It is not allowed here for data and fax calls but 
it is allowed for speech and alternate speech/fax. If the 
parameter is left out (as in the SMS case), information in the 
BC will be used to determine eventual tone protection. 

• TPI is used to prevent tone sending for certain types of calls. 

• Transmission Break Protection (TBP). Protects against breaks 
in the transmission. Only set for fax and data calls. 

• Traffic Class (TCL). A value that is used in case of mobile 
originating call to PSTN to identify call type. Only specified 
for fax and data calls. 

Commands for Telecommunication Service Analysis Data 

MGTEI and MGTCI are used to define the Telecommunication 

Service Analysis. Examples: 


MGTCI : TSC=1 , WS IG=NOI S , TBP=NO, TPI=YES , NOTE= "THY " ; 


A TSC for speech is defined with no requirement on signaling 
capabilities (NOIS) transmission breaks (TBP) are not protected 
(that is, they are allowed) and tone sending (TPI) is allowed. 
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MGTEI : TEC=THY, CRT=DFR-DFRC , PSCVL=FRV1 &FRV3 , TSC=1 ; 


The radio channel requirement (RCR) defined for TSC=1 is a dual 
rate channel, full rate preferred. The selected channel rate and type 
(SCRT) is dual rate, full rate preferred with change allowed after 
first channel allocation. The provided speech coder version list 
contains the speech coder full rate version 1 and 3. 


MGTCI : TSC=21, WSIG=ISPR, TBP=YES , TPI=NO, TCL=12, 
NOTE= "DA_ANT " ; 


A TSC for asynchronous data transmission is defined with ISDN 
preferred. Transmission breaks and tone sending are not allowed. 


MGTEI : BEG=DCDA, URATE="0, 3", TRI=NT, CRT=FR-FR& 
DFR-FR, TSC=2 1 , NIRA=1 ; 


The Radio Channel Requirement (RCR) defined for TSC=21 is full 
rate and dual rate, full rate preferred. The corresponding selected 
channel rate and types (SCRT) are both full rate. Negotiation of 
intermediate rate is allowed for this service. 


DATA TRANSCRIPT TELECOMMUNICATION SERVICE ANALYSIS 


In the following figures example definitions are given for a 
telecommunication service analysis. For a complete explanation of 
the parameters and the possible values see OPI Mobile Telephony, 
Telecommunication Service Analysis Data, Define. 


* * * _TE LE C OMMUN I CAT I ON_S E RV I CE_COD E D AT A_ * * * ; 

MGTCI :TSC=11, WSIG=NOIS, TBP= NO, TPI=YES, NOTE="THY " ; 
MGTCI :TSC=12, WSIG=NOIS, TBP= NO, TPI=YES, NOTE= " AUXTHY " ; 
MGTCI :TSC=99, WSIG=NOIS, TBP= NO, TPI=YES, NOTE= " EMERG " ; 


* * *_TELECOMMUNICATION_SERVICE_ANALYS IS_DATA_* * * 

*** GSM *** 

MGTEI : TEC=THY, TSC=11 , CRT=FR-FR, PSCVL= 

MGTEI :TEC=THY, TSC=11, CRT=DFR-DFRC , PSCVL= 

MGTEI :TEC=THY, TSC=11 , CRT=DHR-DHRC, PSCVL= 

MGTEI : TEC=AUXTHY , TSC=12 , CRT=FR-FR, PSCVL= 

MGTEI :TEC=EMERG, TSC=99, CRT=FR-FR, PSCVL= 

MGTEI : TEC=EMERG, TSC=99, CRT=DHR-DHRC&DFR-DFRC, PSCVL= 


FRV1&FRV2; 

FRVl & FRV2 & HRVl ; 
FRVl & FRV2 & HRVl ; 
FRV1&FRV2 ; 
FRV1&FRV2; 

FRVl & HRVl; 


*** UMTS *** 

MGTEI :TEC=THY, TSC=11 ,UMTS; 

MGTEI :TEC=AUXTHY, TSC=12 ,UMTS; 

MGTEI :TEC=EMERG, TSC=99 ,UMTS; 

Figure 8-9: Definitions for Speech in GSM and WCDMA systems 
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* * *_TELECOMMUNI CAT ION_SERVI CE_CODE_DATA_* * * ; 

MGTCI : TSC=13 , WSIG=NOIS, TBP= NO, NOTE="SMSMO" ; 
MGTCI : TSC=14 , WSIG=NOIS, TBP= NO, NOTE= " SMSMT " ; 

* * *_TELECOMMUNI CAT ION_SERVICE_ANALYS I S_DATA_* * * 

MGTEI :TEC=SMSMO, TSC=13; 

MGTEI : TEC=SMSMT , TSC=14; 

Figure 8- 1 0: Definitions for Short Message Service 

* * *_TELECOMMUNICATION_SERVICE_CODE_DATA_* * * ; 

MGTCI :TSC=15, WSIG=ISPR, TBP=YES, TPI= NO, NOTE="AFX3 
TCL=6 ; 

MGTCI :TSC=24, WSIG=ISPR, TBP= NO, TPI=YES, NOTE="ALTSPFA" , 
TCL=6 ; 


* * *_TELECOMMUNICATION_SERVICE_ANALYS IS_DATA_* * * 

*** GSM *** 

MGTEI : TEC=AFX3 , TSC=15, TRI=T , ACC="14.4"; 

MGTEI :TEC=ALTSPFAX, TSC=24, TRI=T, PSCVL=FRV1&FRV2 , ACC=" 14 . 4 " ; 

Figure 8-11: Definitions for FAX in GSM (No support of circuit switched 
FAX in WCDMA) 


* * *_TELECOMMUNICATION_SERVICE_CODE_DATA_* * * 


MGTCI :TSC=16, 

WSIG=ISPR, 

TBP=YES, 

TP I 

= NO, 

NOTE="DA 

D 

NT", 

TCL=6 

MGTCI :TSC=17, 

WSIG=ISPR, 

TBP=YES , 

TP I 

= NO, 

NOTE="DA 

D 

T" , 

TCL=6 

MGTCI :TSC=27, 

WSIG=ISRE, 

TBP=YES , 

TP I 

=NO, 

NOTE="DA 

UDNT " , 

TCL=6 


***_TELECOMMUNICATION_SERVICE_ANALYSIS_DATA_*** 

*** GSM *** 

MGTEI :BEG=DCDA, TSC=16, ITC=UDI , TRI=NT, FNUR=" 56 . 0 " , ACC=" 14 . 4 " 9 . 6" & " 4 . 8 " ; 
MGTEI :BEG=DCDA, 130=16, ITC=UDI , TRI=NT, CRT=FR-FR, URATE = " 4 .8"; 

MGTEI : BEG=DCDA, TSC=16, ITC=UDI , TRI=NT, CRT=FR-FR, URATE = " 9.6"; 

MGTEI : BEG=DCDA, TSC=17 , ITC=UDI , TRI=T , FNUR= "14.4", ACC= " 1 4 . 4 " & " 9 . 6 " & " 4 . 8 " ; 
MGTEI :BEG=DCDA, TSC=17, ITC=UDI , TRI=T, CRT=FR-FR, URATE = " 4 .8"; 

MGTEI : BEG=DCDA, TSC=17 , ITC=UDI , TRI=T, CRT=FR-FR, URATE = " 9.6"; 


*** UMTS *** 

MGTEI :BEG=DCDA, TSC=27, ITC=UDI, TRI=NT, SERVICE=BASIC, FNUR="38.4"; 

Figure 8-12: Definitions for asynchronous digital data calls (UDI, V.110) 

* * *_TELECOMMUNICATION_SERVICE__CODE_DATA_* * * ; 

MGTCI :TSC=18, WSIG=ISPR, TBP=YES, TPI= NO, NOTE="DA A NT", TCL=6; 

MGTCI :TSC=19, WSIG=ISPR, TBP=YES , TPI= NO, NOTE="DA A T", TCL=6; 

* * *_TELECOMMUN I CAT I ON_SERVI CE_ANAL Y S I S_D ATA_* * * 

*** GSM *** 


MGTEI :BEG=DCDA, 
ACC=" 14 . 4"&"9. 6' 

TSC=18 , 
' & " 4 . 8 " ; 

ITC=AUD, 

TRI=NT, 

FNUR= "28.8' 


MGTEI :BEG=DCDA, 

TSC=18 , 

ITC=AUD, 

TRI=NT, 

CRT=FR-FR, 

URATE = " 4 . 8"; 

MGTEI :BEG=DCDA, 

TSC=18 , 

ITC=AUD, 

TRI=NT, 

CRT=FR-FR, 

URATE=" 9.6"; 

MGTEI :BEG=DCDA, 
ACC=" 14 . 4"&"9. 6' 

TSC=19, 
' & " 4 . 8 " ; 

ITC=AUD, 

TRI= T, 

FNUR= "14 .4' 


MGTEI :BEG=DCDA, 

TSC=19, 

ITC=AUD, 

TRI= T, 

CRT=FR-FR, 

URATE = " 4 .8"; 

MGTEI :BEG=DCDA, 

TSC=19, 

ITC=AUD, 

TRI= T, 

CRT=FR-FR, 

URATE=" 9.6"; 

*** UMTS *** 

MGTEI :BEG=DCDA, 

TSC=18, 

ITC=AUD, 

TRI=NT, 

SERVICE=BASIC, FNUR="28 


Figure 8-13: Definitions for asynchronous analog data calls (MODEM) 
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* *TELECOMMUNICATION_SERV . ANA . DATA FOR MULTI SLOT SERVICES** 
MGMT I : BEG=DCDA , TRI =NT , I TC=UD I , FNUR= "56.0", 

ACC=" 14 . 4"&"9. 6"&"4 . 8 " , MTCH=4 , TSC=16 ; 

MGMT I : BEG=DCDA, TRI=NT, ITC=AUD, FNUR="28 . 8" , 

ACC=" 14 . 4 " & " 9 . 6 " & " 4 . 8 " , MTCH=4 , TSC=1 8 ; 

MGMT I : BEG=DCDA, TRI=T, ITC=UDI , FNDR=" 38 .4", 

ACC=" 4 . 8 " & " 9 . 6" & " 14 . 4 " , MTCH=4 , TSC=17 ; 

MGMT I : BEG=DCDA, TRI=T , ITC=AUD , FNUR= "28.8", 

ACC=" 14 . 4 " & " 9 . 6 " & " 4 . 8 " , MTCH=4 , TSC=1 9 ; 


Figure 8-14: Definitions for High Speed Circuit Switched Data calls 
(HSCSD) 
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TRANSMISSION MEDIUM REQUIREMENT ANALYSIS 

Transmission Medium Requirement (TMR) analysis belongs to the 
Traffic Control Subsystem (TCS). This analysis is started when no 
BASC is available to determine a TSC value, the signaling and 
transmission capabilities. Therefore an estimated value defined for 
the incoming route (command ANRSI, parameter TMR) or a 
system defined default value is taken as input. TSC, TPI and TBP 
are obtained. Figure 8-16 illustrates this analysis. 

Input to the analysis is: 

• Transmission Medium Requirement (TMR) 

Output of the analysis is: 

• TSC used for charging and as pointer in TECA to: 

• Tone Protection Information (TPI) 

• Transmission Break Protection (TBP) 

If TSC has no associated values for TBP and TPI, they receive 
default values. 


TMR 



TSC --> (Charging) 

TPI 

TBP 


Figure 8-15: Transmission Medium Requirement Analysis 
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COMPATIBILITY CHECK 


The Compatibility Check (CCH) is initiated by route analysis 
(command ANRSI, parameter CCH=YES). It determines whether 
or not the route is compatible for the service. Three cases exist: 

• Outgoing Call 

• Terminating BL Call 

• Terminating MS Call 

Figure 8-17 illustrates the Compatibility Check for an outgoing 
call. 

WSIG, TMR 
for service 


TTRANS, TSIG 

from outgoing route 

Figure 8-16: Compatibility Check (CCH) of Outgoing Calls 
Input parameters are: 

• WSIG - This parameter is the result of the BASC analysis for mobile 
originated calls. 

TMR - from originating side. 

• Trunk Transmission Characteristic (TTRANS) - TTRANS is the 
transmission characteristic for the route obtained from route data 
(command EXROP). 

• Trunk Signaling Capabilities (TSIG) - TSIG are the signaling 
capabilities of the route. TSIG is hard coded. 

• Output of the analysis is: 

• The call is compatible or not compatible. 

In cases where the call is not compatible for this route, an alternate 
route is tried. 


MTECA 


► 

► 


compatible or 


incompatible 
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9 Mobile Originating Call 


Objectives 


Highlight the analysis required for a mobile originating call as per the 
system documentation. 



Understand the basic principle of A-number analysis and A-number 
pre-analysis 

List the commands and the parameters in the A-number and A- 
number pre-analysis table 
Define Pre B-Number Analysis 
Configure the B-Number Analysis table. 

Understand the basic concept of access barring analysis and time 
supervision. 

Define access barring analysis and time supervision analysis tables 
Build the exchange data required to support calls from an MS/UE by 
interpreting exchange requirements. 



Figure 9-1. Objectives 
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INTRODUCTION 

In this module, only the Data Transcript to support a mobile 
originated call will to be considered. Many of the areas of analysis, 
for example, B-number analysis, access barring analysis, and 
routing case analysis should be familiar from previous courses, so 
only the new or different aspects will be considered in more detail. 

This module will involve the writing of data transcript in a number 
of different sub-files. 
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GENERAL 


Figure below shows the nodes and information involved for a 
mobile originated call. 



Analysis checks of BC 
B number 
A number 
Access barring 


1 B number sent 

IMSi 
B-No 
BNT 
NAPI 
BC 


Figure 9-2: Call from MS/UE 

The following sequence of events occurs: 

1 The MS sends a DTAP message to the MSC-S Blade Cluster 
containing a Bearer Capability (BC), the B-number, along with 
other information describing the B-number. The other 
information includes the B-number Type (BNT) and the 
Numbering Plan Indicator (NAPI). The Bearer Capability (BC) 
describes the type of service required for the call. For example, 
it could be a telephony call, a fax call, a data call or even a 
short message call. The Numbering Plan Indicator (NAPI) 
always indicates that the B-number is based on the E.164 
series, NAPI=1 and the B-number Type (BNT) usually 
indicates that the B-number is of an unknown type, BNT=2. 
However, if the ‘+’ key (the ‘+’ key is used instead of the 
international access code 00, that was internationally not 
unique) is used, BNT would indicate that the B-number was in 
the international format BNT=1. 

2 A whole range of analysis takes place in the MSC-S as 
indicated in previous figure, before an outgoing route is 
selected. 
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3 The call would then be routed to other nodes or networks 
according to the B -number and Routing Case analysis. This 
could either be towards a PSTN or ISDN network or possibly 
towards a PLMN (GMSC). 

This is a brief introduction to the mobile originating call. Figure 
9-3 gives a more detailed illustration of the mobile originating call. 

CALL FROM MS/UE 



Figure 9-3: Call from MS/UE Detailed 

1 The MS sends a SETUP message containing every necessary 
information (IMSI, B-number,...) to the MSC-S BC. The SPX 
node selected for this call setup choose a MSC Blade. This 
MSC Blade will check if its responsible for that subscriber. If 
not, will transfer to the correspondent MSC Blade to complete 
the call setup. Once the MSC Blade is identify, it the IMSI is 
analyzed in the VLR. 

2 Authentication is performed by the MSC-S, if defined in the 
network. The ciphering is initiated and the IMEI is validated by 
the EIR. 


LZT 123 9083 R1 A 


© Ericsson 2009 


- 221 - 





MSC-S R13.1 Blade Cluster Data Transcript 


ERICSSON ^ 


Note: Ciphering and authentication are optional and are defined by 
the network operator. In the WCDMA Authentication mechanism, 
the quintuplet (RAND, XRES, CK, IK and AUTN) replaces the 
“triplet” (RAND, SRES, Kc). Every Authentication is performed 
using fresh quintuplets. The Ciphering Key (CK) is increased in 
length compared to the GSM Ciphering Key (Kc). To provide 
security of the signaling between the user and the MSC/MSC-S, a 
function known as Signaling Integrity Protection is introduced with 
a new information element, Integrity Key (IK). The new 
Authentication Token (AUTN) is also introduced. The XRES 
replaces SRES in WCDMA Authentication and has the same 
function as SRES in GSM. RAND has the same function as in 
GSM. 

See additional information for authentication process by using the 
parameters listed in the command MGEPP. 

3 The MSC-S receives a set-up message from the MS/UE. 
Included in this information is the type of service the MS/UE 
wants and the number (called the B -number) dialed by the 
mobile subscriber. The MSC-S checks that the mobile 
subscriber does not have services, such as barring of outgoing 
calls activated. (Barring can be activated either by the 
subscriber or by the operator.) If the mobile subscriber is not 
barred, the setting up of the call proceeds. In order to complete 
the call, the MSC-S can already seize all required resources by 
sending a SEIZE RESOURCE message to the MGW. The 
MGW selection vary depends on traffic case and configuration 
data. 

4 The MGW returns an ACKNOWLEDGE message to the MSC- 
S. All the necessary resources in MGW are reserved. 

5 The MSC-S informs the BSC/RNC that the call setup is 
proceeding with a CALL PROCEEDING message. 

6 The MSC-S requests the BSC/RNC to set up a connection to 
MGW with an ASSIGNMENT (BSSAP) / RAB 
ASSIGNMENT REQUEST (RANAP) message. 

7 After the connection set up complete, the BSC/RNC informs 
the MSC-S with ASSIGNMENT COMPLETE (BSSAP) / RAB 
ASSIGNMENT RESPONSE (RANAP) message. 
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8 The traffic control subsystem (TCS) in the MSC-S Blade 
Cluster analyzes the digits and sets up the connection to the 
called subscriber (ISDN, PSTN or another PLMN) via a 
corresponding TSC Blade. In this case, the MSC Blade sends 
via INTRO route to the TSC Blade and it will set up the 
connection towards the next node/network (ISUP or BICC 
route). 

9 Once all the necessary resources to the called subscriber are 
reserved, an ALERTING message is sent to the MS/UE, 
indicating that a ringing tone has been generated on the B- 
subscriber side. The tone generated in the exchange on the B- 
subscriber side is sent to the MS/UE via the Group Switch (GS) 
in the MSC or via GCP protocol to inform MGW to generate 
the tone. This means that it is sent over the air, not generated in 
the MS. 

10 When the B -subscriber answers, the TSC Blades sends it to the 
MSC Blade and the MSC Blade sends a CONNECT message 
to the MS/UE to indicate that the call is accepted. 

1 1 The BSC/RNC sends back an ACKOWLEDGEMENT message 
to the MSC-S. The connection between the A-subscriber and 
the B-subscriber is now activated. The GSM/WCDMA system 
speech call can now take place. 
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ANALYSIS FUNCTIONS 


For a mobile originated call to be routed, a number of analysis 
functions are required. A general analysis diagram is show below. 
This is applied for MSC and TSC blades. Except IMSI Origin 
Analysis is not done in TSC Blades. 


Incoming Call 



Route 

Origin 


Figure 9-4: Analysis Functions 


IMISI 

Origin 


Sub- 

Class 



Access 

Barring 


Outgoing Call 


Routing 

Case 


Route 


PSTN 


EOS 


Terminating Call 
MTE 


Mobile 


TELECOMMUNICATION SERVICE ANALYSIS 

The telecommunication service analysis was covered in the 
previous chapter 9 - ‘Telecommunication Service Analysis’. A 
summary is shown in the next Figure. 

The purpose of the telecommunication service analysis is to 
determine whether or not the MSC/VLR supports this type of call. 
If the MSC/VLR does not have a DTI, any data or fax call would 
fail because the DTI is necessary in order to support the call. 

The GSM or WCDMA Bearer Capability from the MS is converted 
into Basic Service Codes (BASC). The BASC is then analyzed. If 
this requested service is not supported in the MSC/VLR, the BASC 
for this service would not be defined in MTECA. The call would 
then fail. If the call is supported, the requirements etc. for the call 
would be obtained. 

The Data Transcript for the Telecommunication Service Analysis 
function would normally be a standard set of data, which would be 
used from one switch to the next. Maybe slight editing would be 
needed. 
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GSM or 
WCDMA 
Bearer 
Capability 



THY 

EMERG 

ALTFAX 

AFX3 

SMSMO 

SMSM7 


DCDA “0.3” 
DCDS “1.2” 
“2.4” 
“4.8” 
“9.6” 


TRI 
RSIG 
ITC 
CRT 
PSCVL 
1.2/0.075” NIRA 


NO 


FAIL 


T1VIR - ANRSI 

WSIG - ANRSI 

TSC - CHARGING 

TPI -EOS 

TBP 


Figure 9-5: Telecommunication Service Analysis 


If the requested service is supported, the call can proceed with 
checks on the IMSI, the B-number and the subscription checks. 


IMSI NUMBER SERIES ANALYSIS 


Incoming Call 



Route 

Origin 


IMISI 

Origin 


Sub- 

Class 



Access 

Barring 


Outgoing Call 


Routing 

Case 


Route 


PSTN 


EOS 


Terminating Call 
MTE 


Mobile 


Figure 9-6: IMSI Number Series Analysis 


Information about the MS/UE is fetched from the IMSI number 
series analysis (the MGISI command) table defined in all MSC 
Blades. This information includes the following parameters: 


OBA 


Origin for B-number Analysis - specifies which B -origin the 
MS/UE is to use for the mobile originated call. 
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CBA 


Call Barring Access is used in connection with the BOIEXH 
supplementary service (Barring of all Outgoing International calls 
Except those directed towards the Home PLMN), 


NATMS 

National Mobile Subscriber is used to determine how the A- 
number is presented. The default is in the International format, but 
this parameter puts the A-number in the National format. 

OWNMS 

OWN Mobile Subscriber is used to identify the subscriber as one 
that belongs to this PLMN, that is, this is the subscriber’s HPLMN. 

CBAZ 

This parameter, Call Barring Access for Inter-Zonal Calls except 
those directed to the HPLMN country, is mandatory. It is used for 
the operator determined barring of inter-zonal calls and indicates 
whether the call is to be barred or not depending on its destination. 

STALL 


This parameter stands for Subscription Type Allowed. It indicates 
whether or not the subscription type stored in the VLR can be used. 
This is an optional parameter. 

All of these parameters are defined using the ANRES parameter. A 
copy is found in the Application information for Mobile Telephony 
Data. To find the parameter values to use or to get an explanation 
of the parameter, the Application Information for the parameter- 
owning block needs to be looked at, for example, the owning block 
for NATMS is MTACC (for a mobile originated call) or MTBSS 
(for mobile terminating calls). 
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B-NUMBER ANALYSIS 


The B -number analysis is central to the whole call setup process as 
shown in the figure below. 


It is recommended to define the most common data transcript for 
B-number table analysis for MSC and TSC Blades. Although some 
data are different such as routing a call to a PSTN, incoming call 
from an another PLMN and so on. 


Incoming Call 



Route 

Origin 


IMISI 

Origin 


Sub- 

Class 



Access 

Barring 


Outgoing Call 



Figure 9-7: B-N umber Analysis 


The B-number analysis is carried out in two stages. The first stage 
is referred to as a Pre-analysis of the B-number and then the 
analysis of the B-number takes place. 


The pre-analysis acts as a filter and then as a selector. Due to the 
pre-analysis, it is possible to reduce and simplify the number of 
origins used in the B-number analysis tables. 


Pre-analysis of the B-number 

The pre-analysis table makes use of the extra information 
contained in the set-up message originating from the MS: the B- 
number Type (BNT) and the Numbering Plan Indicator (NAPI). 
These parameters are generated by the MS/UE or the ISDN 
equipment, and are then transferred from network to network using 
the ISUP protocol. An explanation of these parameters, BNT and 
NAPI, is found in Figure 9-8. 
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NAPI: 0 SPARE BNT: 0 RESERVED 

1 ISDN/PSTN (E.163/E.1 64) 1 INTERNATIONAL 

2 DATA (X.121) 2 UNKNOWN 

3-15 SPARE 3 SUBSCRIBER 

4 NATIONAL 
5-15 SPARE 


Examples: 

009 46 70 533 
070 533 
533 

46 70 533 
70 533 


BNT=2 Unknown format, dialed number 
BNT=2 Unknown format, dialed number 
BNT=3 Subscriber format, SN 
BNT=1 International number, CC+NDC+SN 
BNT=4 National number, NDC+SN 


Figure 9-8: NAPI and BNT Parameter Values 


By using the extra information about the B-number it is possible, 
for example, to direct an international number directly to a B -origin 
containing only numbers in the international format. Figure 9-9 
shows an example of this. 


Filter 

1AM Pre-B B Number 


BNT=2,B=0047..,NAPI=0 


NAPI 

0 



1AM 


NAPI 

1 



BNT=2,B=0047..,NAPI=1 

0> 

1=0 

0 - 00, .. 


Selector 

1AM 


BNT=2,B=0047..,NAPI=1 


1AM 


BNT=1 ,B=47.., NAPI=1 


1=0 

BNT 




2,4 


30 - 00, 


BNT 



o> 

1 

o> 

32 - 47, 


Figure 9-9: Use of Pre B-Number Analysis 


Figure 9-9 shows that the pre-analysis can act as a filter, by using 
the NAPI value and as a selector by using the BNT value. 


Using Figure 9-9, the parameter NAPI is used as an example of 
pre-analysis acting as a filter. If NAPI=0, then the analysis stops 
and goes no further, because it is a spare number plan. However, if 
NAPI=1, the analysis of the B-number would continue in the origin 
indicated. 
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The NAPI and BNT parameters can then be used as selectors, for 
example: If BNT=2 (unknown number type) and NAPI=1 (E.164 
number format), which would be the usual case from the MS/UE, 
the pre-analysis directs the analysis to continue in origin 30. 
However, if BNT=1 (international) and NAPI=1, which would be 
generated if the ‘+’ key is used, then the analysis would continue in 
origin 32. Origin 32 contains the international (country code) 
numbers. 

The other thing to notice when BNT=1 is that the B-number does 
not contain 00. In this case the digits 00 are the international prefix. 


Analysis of the B-number 

Figure 9-10 describes the type of calls each B-origin supports. 
From the example shown in the figure below, only origins 30 and 
32 are of interest regarding a mobile originated call. 

Origin 30, in our example, is where all MS originated calls would 
be sent if they had a BNT value of 2 (unknown). Origin 32 would 
only be used for international calls having a BNT value of 1 
(international); this selection would have been determined in the 
pre-analysis. 

Note: MS/UE only generates BNT values of 2 or 1; it is not able to 
generate a number in national format (BNT=4). 


I •k-k'k'k-k'k'k'k'k-k'k'k-k-k'k-k'k-k-k'k'k'k'k-k-k-k'k'k'k'k'k'k-k-k'k'k-k-k'k'k'k'k'k-k-k-k'k-k-k'k'k'k-k-k-k | 
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TO 

II 
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1 
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* | 
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! * 
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II 

o 
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TO 

II 

CD 

O 

AIRTIME CHARGING 

* i 

! * 
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MSMO CHARGING 

* i 
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II 
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Figure 9-10: Use of B-origins 
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B-Origin 30 

B -origin 30 will have to contain all the number series that can be 
expected from the MS/UE. However due to the pre-analysis, only 
numbers of an unknown type (BNT=2), will need to be defined. 
This would include calls directed to the PSTN, which usually have 
a national 0-prefix. Emergency calls also need to be considered, for 
example, both the national emergency number and the 
GSM/WCDMA emergency number (112). This analysis should 
present the number in a national format and set the BNT 
accordingly (BNT=4). 

B-Origin 32 


B-origin 32, in our example, will contain all numbers in the 
international format, that is, beginning with a country code. Again, 
this would have been achieved through the use of pre-analysis 
when BNT=1. Remember that it is the mobile which has generated 
the value of BNT=1. In reality this table would need to include all 
country codes in the world. 


BO 

NAP I 

BNT 

OBA 



30 

i 

2 

30 


B=30-00, M=2 , BNT=1 , F=OR 

B=30-01 925 , BNT=4 , M=1 

RC=..., CC=..., D=4 — 1... 

30 

i 

1 

32 


B=32-47,RC=..., CC=...,D=6-63, 


EXAMPLE 1 

BO=30, NAP 1 = 1, BNT=2, B=30-0047... 

EXAMPLE 2 

BO=30, NAP 1 = 1, BNT=1, B=32-47... 

EXAMPLE 3 

BO=30, NAP 1 = 1, BNT=2, B=30-01925... 

Figure 9-11: Examples of B-N umber Analysis 

Figure 9-11 shows how B-number analysis works using three 
examples. 
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EXAMPLE 1 


The BO parameter has been received from the IMSI Number Series 
Analysis (the OBA parameter in the MGISI). However, the BNT 
and NAPI parameters and the B-number are received as part of the 
SETUP message from the MS. 

The number plan is specified in the E.164 series (NAPI=1) and the 
B-number from the MS/UE is of an unknown type (BNT=2). The 
B-number starts with the digits 00 (international prefix digits), 
indicating that access to the international network is required. 

It can be seen from pre-analysis, that the B-number is to be 
analyzed in origin 30 (result: OBA=30). In origin 30, 00 is 
identified with the following outcomes: 

1. Remove the first 2 digits (M=2), 

2. Change the number type to be international (BNT=1), 

3. Return to the original origin in pre-analysis (F=OR) for further 
analysis. Here the NAPI and BNT parameter values are re- 
analyzed and their explanation continues with example 2. 


EXAMPLE 2 


The BO parameter has been received from the IMSI Number Series 
Analysis (or from B-origin 30 if following on from example 1), 
whilst BNT, NAPI and the B-number have been received as part of 
the SETUP message from the MS. 

The number plan is that specified in the E.164 series (NAPI=1), the 
number from the MS/UE is of an international type (BNT=1), and 
the B-number starts with the digits 47, a Country Code. 

In pre-analysis with BNT=1, the analysis of the B-number is to 
continue in origin 32 in the B-number analysis table. In origin 32, 
47 is the number series identified, at which point a routing case 
(RC), the charging case (CC) and an access barring parameter (D) 
are identified (in this example). An explanation of these parameters 
will take place in the following sections. 
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EXAMPLE 3 


The BO parameter has been received from the IMSI Number Series 
Analysis, whilst BNT, NAPI and the B-number have been received 
as part of the SETUP message from the MS. 

The number plan is that specified in the E.164 series (NAPI=1). 
The number from the MS is of an unknown type (BNT=2), and the 
B-number starts with 0 (national prefix), indicating that the call is a 
national PSTN call. 

The pre-analysis selects origin 30 for the B-number to be analyzed. 
The outputs for the number series 01925 are to: 

1. Remove the 0 (M=l). 

2. Change the number type to national (BNT=4). 

3. Identify which access barring table to use (D=4-l) for any of 
the call barring supplementary services. 

4. Identify a charging case (CC) to be used in the initial charging 
analysis. 

5. Assign a routing case (RC) for the call to be routed to the 
PSTN. 

Parameters used with ANBSI 

Figure 9-12 shows some of the important parameters that are to be 
used with the ANBSI command. There are many more parameters; 
for more information (the meaning and use) regarding the 
parameters. See the COD and ADI. 

Main parameters for ANBSI 

L Length, number of digits expected 

F Analyze digits in a new origin from the FIRST digit 

N Analyze digits in a new origin from the NEXT digit 

RC Routing Case 

CC Charging Case 

M Modify the B-number 

BNT B-NumberType 

NAPI Number Plan Indicator 

D Access Barring 

AW A-number Wanted 

CW A-subscriber Class Wanted 

MTE Mobile Terminating Call 

TE Terminating Call 

EAP Equal Access Prefix 

CIC Carrier Identification Code 

ISTI IN Service Trigger 

Figure 9-12: B- Number Table Parameters 
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L - Length 

This parameter specifies the number of digits that arrive in the 
exchange. If the exact value is not known, a range should be 
specified, for example, L=10-14. 

F - First digit 

If a number needs to be analyzed in another origin starting with the 
first digit, this parameter would be used, if all the digits need to be 
analyzed. The parameter is usually used in conjunction with the 
modification parameter M. If F=OR, the analysis goes back to the 
original origin in the pre-analysis table. 

N - Next digit 

If a number needs to be analyzed in another origin from the next 
digit, this parameter would be used. 

RC - Routing Case 

This specifies the Routing Case and will be the input into Routing 
Case Analysis. This parameter would end any further analysis of 
the B-number unless there is a F or N parameter used. 

CC - Charging Case 

This specifies the Charging Case and will be the input into 
charging analysis. 

M - Modification 


This parameter allows a received number to be modified. This 
could be the removal of some digits, or the addition of some digits, 
or the removal and addition of some digits. The modification starts 
with the first digit received. Examples: the removal of some digits 
is M=3, addition of some digits is M=0-123 and the removal and 
addition is M=l-44. 

BNT - B -Number Type 

If the signaling system used to transfer the B-number does not 
allow the Type Of Number (TON) to be transferred, the default 
value is of type ‘unknown’ (BNT=2). After analysis it is possible to 
change this value to reflect the actual number. If the number is also 
modified, BNT should be inserted to reflect the change. The value 
of this parameter will stay with the B-number throughout the call. 
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NAPI - Numbering Plan Indicator 

This parameter works in the same way as the BNT but determines 
the numbering plan being used, for example E.164. 

D - Access Barring 

Access Barring is used to determine whether or not a subscriber is 
allowed to make a particular type of call, for example an outgoing 
international call. This parameter points to another table where 
further analysis takes place. 

AW - A-number Wanted 


If the A-number is not transferred as part of the signaling system 
and is required, this parameter should be used. It is often used 
when routing a call to the gateway function (route GRI). 

CW - A-number Class Wanted 


If the A-numbers class is not transferred in the signaling system, 
but is required, this CW parameter should be specified. Again this 
would be used when routing to the GRI. 

MTE - Mobile Terminating Call 

This parameter is used to identify the received number as an 
MSRN. The parameter can only be used when the MSRN is 
analyzed to the hundreds group that is, MSRN in national format. 

TE - Terminating Call 

This parameter is used to terminate a call to a locally connected 
subscriber, for example a BL test phone. 

EAP - Equal Access Prefix 

Equal Access Prefix is part of the carrier access code and is used to 
indicate that a carrier identification code (CIC) follows at the start 
of the called number. 

This parameter indicates that an equal access prefix was dialed. 
Digit string 1 - 3 digits. Each digit is 0 - 9. 

The availability of this parameter depends on commercial 
agreements. 
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CIC - Carrier Identification Code 


Carrier Identification Code is part of the carrier access code and is 
used to identify an inter-exchange carrier (IXC). This parameter 
contains the carrier identification code of the dialed carrier. 
Digit string 1 - 6 digits 

Each digit is 0 - 9. 

ISK - IN Service Key 

This parameter is explained here but will not be used. The 
parameter is used to identify that the call requires access to the IN 
node. This value is used as a branching parameter in RC analysis. 


ACCESS BARRING ANALYSIS 


The access barring analysis is defined in the MSC and TSC Blades. 


Incoming Call 



Route 

Origin 


IMISI 

Origin 


Sub- 

Class 



Access 

Barring 


Outgoing Call 



Route 


PSTN 


EOS 


Terminating Call 
MTE 


Mobile 


Figure 9-13: Access Barring Analysis 


Access barring analysis is the method of determining whether an 
MS is permitted to make a call. It works in conjunction with the 
call barring (BAOC, BOIC, BOIEXH) or operator determined 
barring (OBA, OBI, OBO, OBOPRE, OBOPRI, OBZO, OBZI, 
OSB1, OSB2, OSB3, OSB4) supplementary services. 


This function is invoked by the use of the D parameter from the 
analysis of the B-number and points to a table for access barring. 
The meaning of the D parameter can be found in the application 
information for block DA. For each table, a number of Traffic 
Destination Classes (TDCL) exist. The TDCL value is compared to 
the Calling Barring Access (CBA) value: if they are equal then the 
call will fail and if they are not then the call can proceed Figure 
9-14 shows an example of this. 
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BLOCK DA 


NOT PERMITTED 

TRAFFIC CASE 

► 


PERMITTED 
TRAFFIC CASE 

► 


SUBSCRIBER CATEGORY (CBA) 

Figure 9-14: Example of Access Barring Analysis 

The following call barring and operator determined barring 
supplementary services (BOAC, BOIC, OBO, OBOPRE, OBOPRI, 
OSB1, OSB2, OSB3 and OSB4) have a CBA value defined in the 
parameter list of block MTV, Figure 9-15 gives an example for the 
supplementary services BOAC, OBO-1, BOIC & OBO-2. 

CBA VALUE FOR ALL BARRING ! 
SERVICES INDICATING NO ! 

BARRING ! 

VALUE RANGE 0 ... 63 ! 

GUIDING VALUE = 0 ! 

1 = OPERATOR DETERMINED ! 

BARRING OF ALL OUTGOING ! 

CALLS IS ACTIVE ! 

CBA VALUE FOR OPERATOR ! 
DETERMINED BARRING OF ALL ! 
OUTGOING CALLS AND BARRING ! 

OF ALL OUTGOING CALLS ! 

SUPPLEMENTARY SERVICE ! 

VALUE RANGE 0 ... 63 ! 

GUIDING VALUE = 1 ! 

1 = OPERATOR DETERMINED ! 

BARRING OF ALL OUTGOING ! 

CALLS IS ACTIVE ! 

CBA VALUE FOR OPERATOR ! 

DETERMINED BARRING OF ALL ! 
INERNATIONAL OUTGOING CALLS! 

AND BARRING OF ALL OUTGOING! 
INTERNATIONAL CALLS ! 

SUPPLEMENTARY SERVICE ! 

VALUE RANGE 1 ... 63 ! 

GUIDING VALUE = 2 ! 

2 = OPERATOR DETERMINED ! 

BARRING OF ALL OUTGOING ! 
INTERNATIONAL CALLS IS ! 

ACTIVE ! 

Figure 9-15: Example of CBA Values 


NSYMB CBAVALUEO = 0; 


NSYMB CBAVALUEBAOC = 1; 


NSYMB CBAVALUEBOIC = 2; 


ACCESS BARRING DATA 


DESTINATION 
CODE (D) 


ANDSI :D=l-0, TDCL=1; 

ANDSI :D=2-0, TDCL=1; 

ANDSI :D=3-0, TDCL=1; 

ANDSI :D=4-0, TDCL=1; 

ANDSI :D=5-0, TDCL=1; 

ANDSI :D=6-1, TDCL=1&2&44&46&49; 
ANDSI :D=6-44, TDCL=1&2&46&49; 
ANDSI :D=6-49, TDCL=1&2&44&46; 


TDCL=CBA 


TDCLOCBA 
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The supplementary service BOIEXH uses the CBA value defined 
with the MGISI command (IMSI number series analysis). The 
network operator determines this value; values 13 to 255 are 
available for use. This supplementary service is defined by ETSI in 
the GSM/WCDMA recommendations and must therefore be 
provisioned. 

The supplementary service regarding Barring of Inter-zonal calls 
except to the HPLMN, uses the CBAZ value defined with the 
MGISI command. 

Figure 9-16 shows an example of the access barring function 
working. 

MGISI : IMSIS=23415, , ANRES=OBA-30&CBA-63 ; 

MGISI : IMSIS=26202, , ANRES=OBA-30&CBA-62 ; 

PNBSI : BO=30 , NAPI=1, BNT=2 , OBA=30; 

PNBSI : BO=30 , NAPI=1, BNT= 1 , OBA=32; 

ANBSI :B=30— 01925, D=4-l, ; 

ANBSI :B=32— 44, D=6-63, ; 

ANBSI :B=32-49, D=6-62, ; 

ANDSI :D=4— 1, TDCL=1; 

ANDSI :D=6-62, TDCL=1&2&63; 

ANDSI :D=6-63, TDCL=1&2&62; 

Figure 9- 1 6: Access Barring Analysis MML Commands Required 

Below are four examples of access barring using the data shown in 
Figure 9-16. 

EXAMPLE 1 - BOIEXH 

A MS whose IMSI begins with 23415 and has the BOIEXH 
supplementary service active (BOIEXH- 1) makes an international 
call beginning with a country code of 49. The B-number analysis 
gives D=6-62. When the TDCL values from that access barring 
table are found, it can be seen that a TDCL value (TDCL=63) 
exists which is equal to the CBA value (CBA=63) for the MS. In 
this instance the call fails as the MS is barred from this type of call. 
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EXAMPLE 2 - BOIEXH 

A MS who’s IMSI begins with 26202 and has the BOIEXH 
supplementary service active (BOIEXH- 1) makes an international 
call beginning with a country code of 49. The B-number analysis 
gives D=6-62. When the TDCL values from that access barring 
table are found, it can be seen that no TDCL value exists which is 
equal to the CBA value (CBA=62) for the MS. The call can 
proceed in this instance. 

EXAMPLE 3 - BOIC/OBO-2, INTERNATIONAL 

From Figure 9-15, it can be seen that the supplementary service 
BOIC and OBO-2 has a CBA value of 2 (CBAVALUEBOIC=2). 
Therefore, if an MS with the services BOIC or OBO-2 active 
makes any international call, there will be a match between the 
CBA value and a TDCL value in the access barring table. The call 
will therefore fail. 

EXAMPLE 4 - BOIC/OBO-2, NATIONAL 

If the MS/UE in example 3 were to make a national PSTN call, 
access barring table 4-1 would be selected. In this instance there 
would not be a match between the CBA value and a TDCL value. 
This makes the call to proceed. 

It is important to include the correct D parameter, in the B-number 
analysis table; otherwise the barring of specific call types would 
fail to work correctly. 

TIME SUPERVISION 

All networks have a so-called “numbering plan”. Numbering plans 
are prepared for the international network, national networks, and 
regional networks. 

Within each area, the numbering plan connects a defined number 
series to a specific exchange. In some networks, a fixed number 
length is used. In other networks, the length of the subscriber 
number may vary. 
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When setting up a call to a remote network, perhaps in another 
country, the number length might be unknown. Usually, the 
maximum and the minimum length of the number is known. In the 
B-number analysis, the parameter L is set to 8-10 for example. This 
means that the length of the expected B-number is at least 8 digits 
and not more than 10. What should the exchange do when 8 digits 
have been received from the subscriber? Should more digits be 
entered, or has the last digit been received? The only way to 
determine this is by measuring the time it takes for the subscriber 
to dial the next digit. In normal cases, the time supervision between 
the digits is set to some 15-30 seconds. If we reduce this time to 
about 5 seconds, the exchange will know when the last digit is 
dialled. If no more digits are entered after the 5 seconds, it is 
assumed that the last digit has been dialled. 

TIME SUPERVISION ANALYSIS TABLE 

When a time supervision analysis should be performed, the 
parameter TI is delivered by the B-number analysis. 

The time supervision analysis is used in two cases: 

1. The number length is not known and it is wished to use the 
time supervision to determine this. That is, if no digits 
arrive within a certain time, the whole number is considered 
received. Alternatively, the time supervision can be 
disconnected and information received from another 
exchange that the whole number has been received. 

2. There are two numbers (e.g. 0 and 01) containing routing in 
different directions. The only way of separating these is to 
use the time supervision. If time release is obtained after 0, 
the number is regarded as 0. (An EOS-case must be 
specified). If, on the other hand, the one arrives before time 
release 01 is considered received. 

In both of the above cases the time supervision period can be 
decreased (DTS is specified). The actions may be dependent on 
origin. 

A basic principle is that origin 0 applies to subscribers who dial 
digits directly into AXE, that is, subscribers at home exchange and 
subscribers at subordinate registerless exchanges. To other 
subscribers the normal origin 1 applies. In all, 4 origins may exist. 

• The applicable time supervision case is indicated from the 
B-number analysis. If nothing has been indicated, TI=0 is 
applied, which should be used as normal case. 
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• The time supervision analysis is called only in the case 
when an unknown number length has been specified in the 
B-number analysis. Example L = 8-9 (Min. 8 - Max. 9). 

• If time release is obtained before minimum number length 
has been reached, it will be considered a fault. The action is 
to be specified in the end-of- selection analysis. 

• An unspecified time supervision case gives the same 
analysis result as if the following had been written: 

/ 

| Origin > 0 12 3 

ANTSI : TI=X+ 

| Action >NTS : NTS: NTS: NTS; 

\ 

This involves that if it is not desired, for any origin for time 
supervision, to deviate from the normal time supervision 
(NTS), no time supervision case is to be specified. 

• If both the time supervision case and the number length are 
indicated on the same digit, then first the analysis result 
number length is obtained and after that the time 
supervision case. This means that if the time supervision 
analysis has already been in and for example decreased the 
supervision time because an earlier indicated minimum 
number length has been reached, this analysis result will 
apply until a new minimum length is reached. If a fixed 
number length has been specified, the time supervision is 
applicable until this is reached. To actions which are to be 
taken on the occurrence of time release, however, the new 
time supervision case applies. 

Figure below shows an example of a time supervision analysis 
table. 


<ANTSP:TI=ALL; 


TIME SUPERVISION ANALYSIS DATA 
TI ES TSRES (TO 0-3) 


0 

NTS 

NTS 

NTS 

NTS 

1 

DTS 

NTS 

NTS 

NTS 

2 

NTS 

DTS 

DTS 

DTS 


END 

Figure 9- 1 7 Example of Time Supervision Analysis. 
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COMMANDS AND PARAMETERS 

For specifying a time supervision case the command ANTSI is 
used. In order to change a time supervision case which has been 
introduced earlier, the whole specification is made once again with 
command ANTSI. 

For removing an earlier introduced time supervision case the 
command ANTSE is used. A time supervision case should not be 
erased if any reference to the time supervision case exists in the 
B-number analysis. However there is no automatic check of this, so 
if ANTSE is given the time supervision case is erased anyway, and 
then normal time supervision is used. 

ANTSI 

This command specifies the result of a time supervision analysis 
for a time supervision case with an indication of the measures for 
all four origins for the analysis. A time supervision analysis can be 
used for determining a number length, in those cases in which the 
number length is unknown, or for routing in conjunction with 
similar number series, for example 0 and 01. 

An unspecified time supervision case gives the analysis result 
"normal time supervision" for all origins. 


/ 

\/ 

\/ 

\ 

/ \l 

/ \l 1 

/ \ll 

/ \l 

| NTS | | 

| NTS | | | 

| NTS | | | 

| NTS | | 

ANTSI : TI=ti [ , ES=es ] , +DTS+ | 

+DTS+| | 

+DTS+ | | 

+DTS+ | ; 

| BTS | | 

| BTS | | | 

| BTS | | | 

| BTS | | 

\ /I 

\ /II 

\ /I 1 

\ /I 

\ 

/\ 

/\ 

/ 


Figure 9-18 ANTSI Command. 

TI=ti Time supervision case. (Numeral 0-15) 

Specifies number on the time supervision case. 
Time supervision case 0 constitutes the normal case. 

ES=es End of Selection Case (Numeral 1-9999) 

End-of- selection case with measures specified in the 
end-of-selection analysis. Used for routing after 
time release. 

NTS Normal Time Supervision. 
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DTS Decreased Time Supervision. 

BTS Break Time Supervision. 

NTS, DTS and BTS specify the relevant time 
supervision for the respective origins. The length of 
the supervision period is specified in function 
blocks for incoming device routes. 

Time supervision origins 0-3 can be specified. 

ANTSE 

This command is used to remove a time supervision case. 

If the case is pointed out after removal, the result "normal time 
supervision" applies to all analysis origins. 

ANTSP 

This command initiates a printout of data for a specified time 
supervision case. 

DT EXAMPLE OF TIME SUPERVISION ANALYSIS 

A simple DT example of time supervision analysis is shown in 
Figure 9-19. 

i 

ANTSI : TI=0 , NTS; ! TIME SUPERVISION OF B-NUMBER ANALYSIS 

! IN CASE OF UNDEFINED NUMBER LENGTH 

j 

Figure 9-19 DT Example of Time Supervision Analysis. 

ROUTING CASE ANALYSIS 

Another output from the B-number analysis table is the routing 
case (RC). This parameter is analyzed further in the Routing Case 
Analysis Table to determine the outgoing route for the call to 
proceed. The outgoing route must already have been defined with 
the EXROI and EXRBC commands. 


- 242 - 


© Ericsson 2009 


LZT 123 9083 R1 A 





ERICSSON 


MSC-S R13.1 Blade Cluster Data Transcript 


Incoming Call 



Route 

Origin 


IMISI 

Origin 


Sub- 

Class 



Access 

Barring 


Outgoing Call 


Routing 

Case 


Route 


PSTN 


EOS 


Terminating Call 
MTE 


Mobile 


Figure 9-20: Routing Case Analysis 


Figure above shows the command and the important parameters 
that are used to define the routing case analysis. 

Command: AN RSI 


Parameters: RC 

CCH 

R 

ES 

SP 

Important branching: TIVF 

EA 

RA 

WSIG 

PUVN 


Routing Case 
Compatibility check 
Route 

End of Selection 
Sending Program 

Transmission Requirements 
Emergency area 
Percentage random switch 
Wanted Signal 
PLMN of subscriber number 


RO Route Origin 

IST1 IN Service Trigger Indication 


Figure 9-21: Routing Case Analysis Parameters 


CCH - Compatibility Check 

The compatibility check parameter is used to compare the 
requirements for the service (which have been obtained from the 
telecommunication service analysis) to those offered by the 
outgoing route. If the outgoing side does not meet the requirements 
for the service then the call will be terminated. This parameter 
defaults to YES but should not be applied to non-circuit routing. 

Check the Application Information for the route owning block to 
see whether CCH=YES or CCH=NO. 
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SP - Sending Program 

The sending program determines: 

1. on which digit received a device is to be seized, 

2. on which digit received a seizure signal is to be sent, 

3. from which digit to send to the next exchange. 

For example SP = 441, implies (1) that on the forth digit received a 
device is seized (2) on the forth digit a seizure signal is sent and 
finally (3) we send the digits from the first one received (all the 
digits are sent). 

In many cases, a value M exists which means only when all the 
digits have been received would you seize a device or send a 
seizure signal. 

TMR - Transmission Requirements 

The transmission requirements are determined in the 
telecommunication service analysis. They detail the demands on 
the network to provide certain characteristics for the call. If the 
network cannot meet them, then the call will fail. The values and 
meaning of the TMR can be found in the COD for ANRSI. 

The TMR parameter is used as a branch condition and is used to 
determine whether echo cancellers are required for the call. 

Note: Only speech calls require echo cancellers; data calls do not (a 
data call requires the DTI to support the call). 

EA - Emergency Area 

The emergency area is allocated on a per cell basis, with the 
MGCEC command. The parameter is used to route emergency calls 
to the correct emergency service center. 

WSIG - Wanted Signaling 

This parameter is an output from telecommunication service 
analysis and identifies whether or not ISDN signaling is required 
for the call. 
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PLMN - PLMN of the Subscriber Number 

The value of this parameter is determined in the IMSI Number 
Series Analysis, based upon the IMSIS. The value can be used to 
branch to an announcement in the subscriber’s own language. 


RO - Route Origin 


This value is set on the incoming route with the EXRBC command 
or to a cell with the MGCEC command. The parameter will allow 
the calls from different cells or incoming routes to be routed in 
different ways. 

ISTI - IN Service Trigger Indication 

The value of this parameter has been determined in B -number 
analysis. Different ISTI values will identify different IN services 
and as a consequence different routing will be required. 

IGWT - Incoming Access MGW Type 

This parameter is used only in the Combined MSC Node. The 
value of the parameter identifies the type of the MGW at incoming 
side. The availability of this parameter value depends on 
commercial agreements. 

Examples of Branching 

Routes, which are connected to hardware leading to other 
exchanges or routes to announcements, need to be defined with a 
routing case. Also, certain functions requiring access via a software 
route also need to be defined with a routing case, for example, the 
interrogation of the HLR requires access to the GRI route. 
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ANRPI : RC = 1 ; 

ANRSI : BR= TMR— 0 , P01 = l , R = PSTNO, ESS=0,ESR=1,SP=771; 

ANRSI : BR=TMR— 1&& — 4 , P0 2 = l , R=PSTNO, ESS=0,ESR=0, SP = 771; 

ANRPE ; 

! EXTERNAL ROUTE, TMR USED TO SELECT E C HOC ANCE LLERS OR NOT ! 

ANRPI : RC = 1 0 0 ; 

ANRSI : BR=TMR— 0 ,P 0 1 = 1 , R =TRACK1 , SP=330; 

ANRS I : P 0 1 = 2 , R=TRACK1 1 , SP = 330; 

ANRSI: P01 = 3, E S = 1 1 4 ; 

ANRSI : BR=TMR— 1&& — 4 ,P02 = 1, ES = 114; 

ANRPE; 

! ANNOUNCEMENT ROUTE, 'OUT OF SERVICE / P OWE RDF F ' ! 

ANRS I : RC = 6 0 , R=0GRI2, CCH = NO, SP=MM1, BNT = 1 ; 

! ROUTE TO HLR ! 

Figure 9-22: Routing Case Analysis Examples 

The examples shown in Figure 9-19 illustrate the flexibility of 
routing case analysis. The first example, RC=1, uses the parameter 
Transmission Medium Requirement (TMR) value to decide 
whether an echo canceller is required for the call. For speech calls 
(TMR-O) they are required (ESR=1) but for fax and data calls 
(TMR-1&&-4) they are not (ESR=0). The use of the sending 
program parameter (SP) is also illustrated as is the need for a 
procedure when entering multiple lines within one routing case. 
For a procedure the additional commands ANRPI (to start the 
procedure) and ANRPE (to end the procedure) are required. 

The second example, RC=100, illustrates how it is possible to route 
towards an announcement. By using program one (P01) with three 
lines (PO 1=1, P01=2 and P01=3) it is possible to specify routing 
alternatives in the case of one or more routes being congested or 
unobtainable. 

The final example (RC=60) shows the definition of a routing case 
used to point towards the gateway functionality (GRI route). Here, 
as there are no alternative routes or branching conditions, a 
procedure is not required and so only one line of data using the 
ANRSI command is needed. Also note that as the GRI route is a 
software route, that is, non-circuit related, a compatibility check is 
not requested (CCH=NO). 

Figure 9-20 shows an example of routing alternatives using another 
branching parameter Route Origin (RO) for route selection. The 
example relates to Exchange A. 
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EXROI : R=MSC_BO&MSC_BI, DETY=UPD , FNC=3, SI=ISUP4, SP=2-300; 
EXRBC : R=MSC_BI , BO=30, RO=l , TDCL=15; 


ANRPI : 
ANRSI : 
ANRSI : 
ANRSI : 

RC = 1; 
BR=RO— 0 , 

P01=l, 
P01=2 , 
P01=3, 

R= MSC 
R= MSC 
R= MSC 

_CO, 

DO, 

_BO, 

SP= MM1 
SP= MM1 
SP= MM1 

ANRSI : 
ANRSI : 
ANRPE ; 

BR=RO— 1 , 

P02=l, 
P02=2 , 

R= MSC 
R= MSC 

_CO, 

DO, 

SP= MM1 
SP= MM1 


Figure 9-23: Example of Routing Alternatives 


The RO parameter is defined on a per cell basis and is changed by 
the MGCEC command or as in the example defined on an 
incoming route. 


The example shows a call being routed between Exchange A and 
Exchange C. If a call originates in Exchange A, then RO=0, and the 
call will have a direct path to Exchange C or two alternatives (via 
D or B). However, if the call comes from Exchange B via route 
MSC_BI, then RO=l. As a result there is a direct connection and 
one alternative via Exchange D. This is because there is no point 
sending it via Exchange B, since the call has just arrived from 
there. 


LZT 123 9083 R1 A 


© Ericsson 2009 


- 247 - 








MSC-S R13.1 Blade Cluster Data Transcript 


ERICSSON 


ROUTE DATA 


The route data has already been defined in module 4. The EXROI 
and EXRBC commands were used to define the route data. 


Incoming Call 



Route 

Origin 
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Figure 9-24: Route Data 


A-NUMBER ANALYSIS 

The main purpose of the A-number analysis is to determine the 
parameter value of ACO (A-number Charge Origin). A different 
value for this parameter can be given for each operator roaming in 
the network. The ACO is then used as a branch parameter in the 
Charging Analysis. 

The A-number analysis, like the B-number analysis, is split into 
two parts: pre-analysis and then analysis of the A-number. The A- 
number can only be internationally or nationally significant, 
namely: ANT=1 or ANT=4. The A-number is usually stored in the 
international format, ANT=1. However, if the parameter NATMS 
(National MS) has been defined in the IMSI number series analysis 
(the MGISI command), the A-number will be nationally 
significant, ANT=4. 

The A-number analysis is required for the call to be set up. If an A- 
number series is missed, the call will fail. 

The commands used for the A-number analysis are: 

• PNASI for the pre-analysis 

• ANASI for the analysis of the A-number 
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!** ANALYSIS OF INTERNATIONAL A-NUMBER **! 

ANAZI; 

ANASI : A=0— 0 , STATUS=ZERO ; 

ANAS I : A=0-1 , ACO=l ; 

ANASI : A=0-43 , ACO=l ; 

ANASI :A=0-44,ACO=2; ! UK SUBSCRIBER ! 

ANASI : A=0-45 , ACO=l ; 

ANASI :A=0-46, ACO=0; ! SWEDISH SUBSCRIBER ! 
ANASI : A=0-47 , ACO=l ; 

ANASI : A=0-48 , ACO=l ; 

ANASI :A=0-49, ACO=3; ! GERMAN SUBSRIBER ! 

ANASI :A=0-5, ACO=l ; 

! * * * * ANALYSIS OF NATIONAL A-NUMBER ****! 

ANASI: : A=l— 0, ACO=0 ; 

ANASI: : A=l— 1, ACO=0 ; 

ANASI: : A=l— 2, ACO=0; 

ANASI: : A=l— 3, ACO=0; 

ANASI: : A=l— 4 , ACO=0; 

ANASI: : A=l— 5, ACO=0 ; 

ANASI: : A=l— 6, ACO=0; 

ANASI: : A=l— 7, ACO=0; 

ANASI: : A=l— 8, ACO=0; 

ANASI: : A=l— 9, ACO=0; 

ANAAI; 

! * * * * PRE A-NUMBER ANALYSIS ****! 

PNAZI; 

PNASI : NAPI=1 , ANT=1 , OAA=0 , STATUS=ZERO; ! INT . ! 

PNASI : NAPI=1 , ANT=4 , OAA=l ; ! NAT. ! 

PNAAI ; 

Figure 9-25: A-Number Analysis 
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CHARGING ANALYSIS 

The Charging analysis is only mentioned here to give a fuller 
picture of the mobile originated call, but it will be treated in more 
detail in Chapter 12. 


Incoming Call 


Route 

Origin 


IMISI 

Origin 


Sub- 

Class 


Access 

Barring 



Outgoing Call 



PSTN 


EOS 


Terminating Call 
MTE 


Mobile 


Figure 9-26: Charging Analysis 


It is possible to charge for different parts of the call, namely: 

1 The mobile originating leg (MO TT record) 

2 The roaming call forward leg (RCF TT record) 

3 The mobile terminating leg (MT TT record) 

Figure 9-24 and Figure 9-25 show these three different cases. 

■ MO TT-record 

The MO-leg is generated with 
a CC in the B-number analysis 
in the originating call origin. 






Figure 9-27: Mobile Originating Leg 
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RCF TT-record 

Generated with a 
CC in the B-number 
origin for roaming 
numbers. 


Mobile Terminating 
call 


GMSC/ 

GMSC-S 



MT TT-record 

Generated with a 
CC in the B-number 
origin decided by 
parameter BO on 
route MTB. 


Figure 9-28: Roaming Call Forward and Mobile Terminating Legs 


To generate the Toll Ticketing record a Charging Case (CC) needs 
to be generated from within the B-number analysis. The CC would 
be sent to charging analysis to generate the TT record and then 
store a whole range of information in the record. 


Figure 9-26 shows what happens to the CC. The charging analysis 
is now split into two parts, an initial charging analysis based on the 
type of call and then to charging analysis to generate the Tariff 
Class (TC). The tariff class is only needed if the supplementary 
service Advice of Charge is being used. 


CC 


Select New 
Charging Case 
(NCC) based 
on type of 
call. 



Select Tariff 
Qass based 
NCC and then 
branch on 
AGO, CO etc 



TRAFFIC ACTIVITY BASIC CHARGING 

DEPENDANT CHARGING ANALYSIS 

Figure 9-29: Process for Charging Case Analysis 

It can be seen that a CC has been generated from the B-number 
analysis, which is then analyzed and will generate a new charging 
case (NCC) based on the type of call. For example a telephone call 
and a data call could generate new but different charging cases. The 
new charging case is then analyzed and branching can then take 
place depending on the ACO generated from the A-number 
analysis. 
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END OF SELECTION ANALYSIS 


The End Of Selection (EOS) is used to leave software routines in a 
controlled manner, if something unexpected happens. For example 
EOS might be used to start an announcement routine or to generate 
a busy tone, for example. 


Incoming Call 



Route 

Origin 


IMISI 

Origin 


Sub- 

Class 



Access 

Barring 


Outgoing Call 


Routing 

Case 


Route 


PSTN 


EOS 


Terminating Call 
MTE 


Mobile 


Figure 9-30: End Of Selection Analysis 


Different user blocks will generate an end of selection code, which 
is transferred to the RE (register) function block and then to RA 
(route analysis) to find the course of action required for a particular 
EOS code. The EOS codes and their explanation are found in the 
Application Information for the function blocks concerned. The 
recommended action will also be specified 28 highlight this. 


Block X 


Signal with 
EOS-code 



Figure 9-31: Example of End of Selection Analysis 
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EMERGENCY CALL 

Mobile Subscriber emergency calls are handled as highest priority 
calls. The emergency call number is 112 (911 for ANSI). When this 
number is dialed, the Connection Management (CM) Service 
request message from the MS indicates that this is an emergency 
call establishment. (See Figure 9-29) 


MSC-S 

Sao Paulo 


MGw 



b 

MS/ 

UE 


Figure 9-32: Emergency call 

The emergency call is set up in a manner that is similar to the basic 
traffic case “call from UE” with the exception that some functions 
are invoked/ignored depending on the setting of certain emergency 
call related exchange parameters (these properties are set with the 
MGEPC command). 

• EMCNOIMSI-determines whether an emergency call is allowed 
without a SIM-card. 

• EMCNOLU-determines if an emergency call can be carried out when 
location updating has not been made, when a SIM-card is installed in 
the MS. 

• IMEICONTROLEMR-determines if the IMEI check is to be 
performed for a mobile originated emergency call. 

• IMEIROUTGRYEMR-determines if an emergency call is to be 
rerouted to an announcement or operator in case the MS is not type- 
approved (gray listed). 
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After receiving a request from the UE to set up the call, a 
telecommunication service analysis is performed for the emergency 
call, and an End of Selection (ES) code is generated: 

• 2290 if the call is to be set up with a SIM-card 

• 2577 if no SIM-card is installed in the MS. 


This ES code is converted into a B -number, which is then analyzed 
in the ordinary B-number table. The output from this analysis is a 
Routing Case (RC). 

The Emergency call routing is determined by the RC, RO (Routing 
Origin) and EA (Emergency Area) parameters. The RO and EA 
category is specified on a per cell basis. 


Example: 


■ For GSM: 

<MGCEP:CELL=ALL; 

MT CELL DATA 
CELL CGI 

SJCIa 724-02-60-4 

SJC2a 724-02-61-5 

END 

■ For WCDMA: 

<MGAAP:AREA=ALL; 

MT AREA CLUSTER DATA 

AREA ACET AREAID RO CO EA 

SJCIa SAI 724-02-60-4 0 0 0 

SJC2a SAI 724-02-60-4 0 0 0 

END 


BSC CO RO NCS EA 

BSJC1 4101 

BSJC1 4102 


Figure 9-33: Printout of Cell/Area data 
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ENHANCED EMERGENCY CALL ROUTING 


This feature enables the MSC/VLR to provide access in a more 
flexible way to an increased number of emergency call centers. The 
feature is applicable to all mobile originating calls and thus not 
only to emergency calls (112). (See Figure 9-31). 


b 

114 


Police 

Area 

2 


Figure 9-34: Emergency Call Routing 

Up to 65535 emergency centers with a fixed “normal” telephone 
rerouting number can be defined in an MSC. Up to 16 of these 
emergency centers can be connected to a specific geographical area 
(a cell or a Location Area LA, or the whole MSC, or the 
neighboring MSC area). This is defined with the name of the 
emergency center and an index number between 1 and 16. 

For emergency calls a normal B-No. Analysis is used to convert an 
emergency number into a rerouting number. In the B-No. analysis 
calling, an emergency short number like 110, 112, 114, 90000 will 
result in a SII parameter (Signal Information to Incoming side). 
This parameter is a pointer to the index number. 

With this index number and the originating geographical 
information the rerouting number is determined. 

A schematic flow through the different analysis tables is illustrated 
in Figure 9-32. For more information, read the Adaptation 
Direction of the MERNA block. 
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ANBSI 


DBTSC 

B-nr 114 


SII=32 

32 => APPRN1 => ERIND=] 


B-nr => SII 


xx => APPRN2 




xx => APPRN3 


ERIND=] 

Location 


MGRCI 


MGECI 


ANBSI 


EC=POLICE7 


ERN 






B-nr => R( 


Figure 9-35: Analysis Tables of an Emergency Call Schematic Flow 

DATA TRANSCRIPT FOR ENHANCED EMERGENCY CALL ROUTING 


Connect Emergency Center to Index (ERIND): 

MGRCI:CELL=SPAUL01 ,EC=POLICE7,ERIND=1 ; !For GSM! 
MGRCI:AREA=SPAUL01 ,EC=POLICE7,ERIND=1 ; !For WCDMA! 

■ Define Emergency Center number: 

MGECI:EC=POLICE7,ERN=41 31 3301 1 22; 

Activate the Enhanced Emergency option: 

DBTRI; 

DBTSC:TAB=AXEPARS, SETNAME=GSM1 APTC, NAME=APPERNUSE, VALUE=1; 

Set ERIND value: 

DBTSC:TAB=AXEPARS, SETNAME=GSM1 APTC, NAME=APPERN1 , VALUE=32; 
DBTRE:COM; 

Add Emergency Call in the B-number analysis table: 

ANBSI:B=0-1 14,SII=32,F=1 ,RC=300,L=3-23; IDefault RC! 

ANBSI:B=1-41313301 122,RC=73; 


Figure 9-36. Enhanced Emergency Call Routing DT Example 

If a subscriber calls an emergency number (for example, 114 to the 
police), the AXE parameter APPERNUSE switches the emergency 
routing on (value 1). In the B-Number analysis the emergency 
number (114) results in an SB value (32). This SII value is 
transferred into the ERIND value 1 by the AXE parameters (the 
AXE parameter APPERN1 has the VALUE 32). Therefore SII32 
results in ERIND, equal to 1 to analyze the MGRCI table. With the 
ERIND value and the geographical information on the originating 
call party, the B-number is changed to 41313301122 according to 
the ERN value, and the B-number analysis is continued in a new B- 
origin and results in an RC 73. 
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DATA TRANSCRIPT 

Figure 9-34 shows a schematic of the analysis flow used for 
routing mobile originated calls. End of Selection Analysis can take 
place in any part of this flow, generated by specific blocks, or as 
shown in the diagram can be specified using an ES code by 
command. 



Figure 9-37: Selection of MML Commands for Analysis of a Mobile 
Originated Call 


Note: The A-Number analysis has not been included, as the same 
data would apply to each case. See the example shown in Figure 
9-34. 
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TELEPHONY CALL 


! 16000 , 1 ! 

! **** TELECOMMUNICATION SERVICE ANALYSIS ****! 

MGTEI : TEC=THY, TSC=1, CRT=FR-FR, PSCVL=FRV1&FRV2 ; 

MGTEI : TEC=THY, TSC=1, CRT=DHR-DHRC, PSCVL=FRV1&FRV2&HRV1; 
MGTEI :TEC=THY, TSC=1, CRT=DFR-DFRC, PSCVL=FRV1 &FRV2&HRV1 ; 
MGTCI : TSC=1, WSIG=NOIS, TBP=NO, TPI=YES, NOTE="THY" ; 

! 76000 , 1 ! 

I**** IMSI NUMBER SERIES ANALYSIS **** ! 

MGISI : IMSIS=415 01,M=5-961 32 , NA=4 , ANRES=OBA-30&CBA-63& 
PLMN-0&NATMS& . . . ; 

! 15700 , 1 ! 

! **** PRE B-NUMBER ANALYSIS ****! 

PNBSI : BO=30 , NAPI=1, BNT=1, OBA=22; 

PNBSI : BO=30 , NAPI=1, BNT=2, OBA=30; 


Figure 9-38: Mobile Originated - Telephony Call (1) ALL MSC Blades 

! 15600 , 1 ! 

I**** b-NUMBER ANALYSIS DATA **** ! 

ANBSI : B=30-03, L=8; 

ANBSI : B=30-036, RC=15, CC=3, L=8, D=4-l; 

115400 , 1 ! 

! **** ROUTING CASE ANALYSIS ****! 

ANRSI : RC=15, R=INTR10, SP=MM1; !To TSC Blade! 

115300 , 1 ! 

! **** ROUTE DATA ****! 

EXROI :R— INTRTIO, DETY=INTRO, FNC=1; 

EXRBC : R=INTRT10, RGPAR=DIS-2&BLAO-4 ; 

! 15500 , 1 ! 

! **** ACCESS BARRING ANALYSIS **** ! 

AND SI : D=4— 1 , TDCL=1 ; 

Figure 9-39: Mobile Originated - Telephony Call (2) ALL MSC Blades 

When there is a call to another PLMN or PSTN, it goes to the TSC 
Blades as they have the BICC and ISUP routes to these 
destinations. 


The RC=15 has the INTRO route to TSC Blade. The parameter 
RGPAR in the EXRBC command, DIS-2 represents ‘TSC 
distribution is specified’ and BLAO-4, blade origin. FNC=1 is an 
outgoing route. 

On TSC Blades there should be also an INTRO route related to this 
BLAO-4, i.e. this parameter means the relationship between 
outgoing and incoming traffic data from MSCs and TSCs Blades. 
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! 15600, 1 ! 

! **** B-NUMBER ANALYSIS DATA ****! 

ANBSI : B=30-03, L=8; 

ANBSI : B=3 0-036, RC=6, CC=3, L=8, D=4-l; 

! 15400, 1 ! 

! **** ROUTING CASE ANALYSIS ****! 

ANRSI : RC=6, R=PLMNO, SP=MM1; ! TO PLMN ! 

115300 , 1 ! 

! **** ROUTE DATA ****! 

EXROI : R=PLMNO&PLMNI , DETY=BID, FNC=3, SP=2-15660; 
EXRBC : R=PLMNI , BO=l, CO=31; 

! **** INCOMING ROUTE FROM MSC/TSC BLADE ****! 

EXROI : R=INTRB1I, DETY=INTRO, FNC=2 ; 

EXRBC : R=INTRB1I , RGPAR=BLAO-4 ; 

! 15500 , 1 ! 

! **** ACCESS BARRING ANALYSIS ****! 

ANDSI : D=4-l , TDCL=1; 


Figure 9-40: Mobile Originated - Telephony Call (3) TSC Blades 

INTRO routes act as an internal trunk for interconnecting the 
blades within the cluster. In the TSC blade, the INTRO route 
definition is done by the command EXROI with FNC=2, incoming 
route. The BLAO-4 means that this is receiving traffic data from a 
blade origin 4. 

The same pre- and b-number analysis is done in the TSC blade in 
the same origin as no modification is set in the INTRO routes. 

The result of this analysis is another routing case, now RC=6 which 
is routing to the PLMN using the R=PLMNO. 
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EMERGENCY CALL 


! **** TELECOMMUNICATION SERVICE ANALYSIS ****! 

! GSM! 

MGTEI : TEC=EMERG, TSC=99, CRT=FR-FR, PSCVL=FRV1&FRV2; 
MGTCI : TSC=99, WSIG=NOIS, TBP=NO, TPI=YES, NOTE="EMERG" ; 

! WCDMA ! 

MGTEI :TEC=EMERG, TSC=99 , UMTS; 


! **** END OF SELECTION ANALYSIS **** ! 

ANESI : ES=22 90 , F=30, M=0-112; 

ANESI : ES=2 577 , F=30, M=0-112; 

! **** PRE B-NUMBER ANALYSIS ****! 

PNBSI : BO=30 , NAP 1=1, BNT=1, OBA=22; 
PNBSI : BO=30 , NAP 1=1, BNT=2 , OBA=30; 


Figure 9-41: Mobile Originated - Emergency Call (1) 


! **** B-NUMBER ANALYSIS DATA ****! 

ANBSI :B=30-112, L=3, RC=15, BNT=2 ; !MSC Blades! 

! **** B-NUMBER ANALYSIS DATA ****! 

ANBSI :B=30-112, L=3, RC=2, BNT=2; 

! **** ROUTING CASE ANALYSIS ****! 

ANRPI : RC=2 ; 

ANRS I : BR=TMR- 0 & - 3 & - 4 , R=P S TN 1 0 , SP=MM1 , ESS=0 , ESR=1 , P01=l; 

! EC REQUIRED! 

ANRS I : BR=TMR- 1 & - 2 , R=P S TN 1 0 , SP=MM1 , ESS=0 , ESR=0 , P01=2 ; 

! EC NOT REQUIRED! 

! **** ROUTE DATA ****! 

EXROI :R=PSTN10&PSTN1I, DETY=UPDR, FNC=3, SI=ISUP4, 
SP=2-13555; 

Figure 9-42: Mobile Originated - Emergency Call (2) 


Notice again that the DT in case of MSC Blade, it should be route 
to TSC Blade via INTRO route (RC=15) then the TSC Blade routes 
it to the PSTN. 
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FAX CALL 


!**** TELECOMMUNICATION service ANALYSIS **** ! 

MGTEI :TEC=AFX3, TSC=5, TRI=T, ACC="14 . 4"; 

MGTCI : TSC=5, WSIG=ISPR, TBP=YES, TPI=NO, NOTE="AFX3", TCL=6; 

! **** IMS I NUMBER SERIES ANALYSIS **** ! 

MGISI : IMSIS=4 15 01,M=5-961 32 , NA=4 , ANRES=OBA-30&CBA-63& 
P LMN- 0 & NATMS & ; 

! **** PRE B-NUMBER ANALYSIS ****! 

PNBSI :BO=30, NAP 1 = 1, BNT=1, OBA=22; 

PNBSI :BO=30, NAP 1 = 1 , BNT=2 , OBA=30; 

Figure 9-43: Mobile Originated - Fax Call ( 1 ) For GSM Only 

! **** B-NUMBER ANALYSIS DATA ****! 

ANBSI :B=30-03, L=8; 

ANBSI :B=30-036, RC=15, CC=3, L=8, D=4-l; 

!***★ B-NUMBER ANALYSIS DATA **** ! 

ANBSI :B=30-03, L=8; 

ANBSI : B=3 0-036, RC=6, CC=3, L=8, D=4-l; 

! **** ROUTING CASE ANALYSIS ****! 

ANRSI:RC=6, R=PLMNO, SP=MM1; ! TO PLMN ! 

I**** ROUTE DATA **** ! 

EXROI :R=PLMNO&PLMNI,DETY=UPDR,FNC=3, SI=ISUP4 / SP=2-15660; 

EXRBC : R=PLMNI , BO=l, CO=31; 

EXROI : R=GIWU10&GIWU1 I , DETY=MIWULT, FNC=3, DPC=999; 

EXROI :R=GIWU20&GIWU2I, DETY=MIWULT f FNC=3 f SI=ISUP,DPC=999; 

EXROI : R=DTI1 , DETY=MIWUD; 

!***★ ACCESS BARRING ANALYSIS **** ! 

ANDSI : D=4-l , TDCL=1; 


Figure 9-44: Mobile Originated - Fax Call (2) For GSM Only 
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10 Mobile Terminating Call 


Objectives 




Define exchange data for a mobile terminating call from a 
PSTN/PLMN to a GSM/WCDMA mobile subscriber. 

■ Develop the exchange data used for routing mobile originating 
calls and explain the major parameters. 

■ Write MML supporting a call to an MS/UE by interpreting the 
exchange requirements. 


V 



Figure 10-1. Objectives 
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INTRODUCTION 

This module follows the analysis required to set up a call, from the 
received digits in the GMSC to the paging of the MS. For 
completeness the main data required in the HLR is also considered. 

CALL TOAMS/UE 

In the given example, the MGW nodes are not the main focus here 
as they were described in previous courses as well. 

In the figure below shows the call flow in high level. Detailed 
traffic case inside MSC-S BC is described later on in the Data 
Transcript session. 



Figure 10-2: Call to MS/UE 


The call to the MS/UE is the most involved traffic case to consider. 
It involves both circuit related signaling and non-circuit related 
signaling. 

It is also important to remember that the GMSC as a function is 
only used for calls to an MS/UE. In other words we have an MSC 
with Gateway functionality. The Gateway functionality is only 
required in order to communicate with the HLR. 

Using the previous figure as the basis, the following description 
shows how a call is routed to an MS. 
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12 A call is routed based on the MSISDN to an MSC-S BC 
(internally, first pass to SPX then TSC and then to MSC Blade) 
with Gateway functionality belonging to the HPLMN of the 
subscriber. This might be routed through another network or 
could be initiated in the same exchange (if the call originated 
from another MS). The MSC analyzes the MSISDN and 
determines that before the call can be routed, some addressing 
information from the HLR is required. The only node that can 
interrogate the HLR for information is the Gateway MSC. 
Therefore the call is passed to the Gateway functionality (inside 
MSC Blades). 

13 The Gateway sends a MAP message, Send Routing Information 
(SRI) or Routing Information Request (RIR), to the HLR 
asking for routing information for the MS/UE. The MSISDN is 
transferred in the international format with the MAP message. 

14 The HLR checks the subscription of the MS/UE based on the 
MSISDN and also obtains the IMSI, which will be used in the 
GSM network. 

15 The HLR sends a MAP message, Provide Roaming Number 
(PRN), to the MSC/VLR where the MS/UE is currently located 
(this could be in the HPLMN of the MS/UE or it could be a 
different PLMN if the MS/UE is roaming). The IMSI will be 
transferred with the MAP message. 

16 The VLR checks whether the MS/UE is attached or not. If the 
MS/UE is attached, the MSC/VLR will allocate a Mobile 
Station Roaming Number (MSRN) and link it to the IMSI. 

17 The MSC/VLR will send the MSRN back to the HLR using the 
MAP message, PRN Acknowledge. 

18 The HLR returns the MSRN to the Gateway using the MAP 
message SRI Acknowledgement. The Gateway then passes the 
return MSRN to the MSC for further analysis. 

19 The MSC will analyze the MSRN and then determine how to 
route the call to the MSC where the MS/UE is currently 
located. 

In the above example the MS/UE is located in the same MSC/VLR 
as the call was routed to. In another situation, if the MS/UE is 
located in a different MSC/VLR, the call would need to be routed 
over the network, using own PLMN, PSTN and International 
switches where necessary, using ISUP to set up the call. 
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20 On reception of the ISUP/BICC signal carrying the MSRN, the 
MSC will analyze the number and determine that the MSRN 
belongs to this switch and that the signaling requests the switch 
to set up a call to an MS/UE. 

21 The MS will now be paged in all cells belonging to the LAI in 
which the MS/UE is currently situated. 

Note: The RNC is could be connected via ATM or IP to MGW and 
the BSC is connected via TDM only. The signaling and when the 
MGW selections are not discussed here. 
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DATA TRANSCRIPT 

The following descriptions will consider the data transcript 
required in each of the above nodes and will be based on the 
description shown in previous figure. 

It is important to consider the various B -numbers that can be 
presented to MSC-S BC. From the network plan (for our first 
example network) we need to consider that the number could be 
directed to a BL device, that is, a test call. The number could be an 
MSISDN and it can also be an MSRN for a call to a mobile in 
MSC-S BC. 

All of these numbers are in the range 961 3 200000 to 961 3 
599999. 

ANALYSIS OF MSISDN IN MSC-S BC 

The MSISDN can be received from one of two places; either an 
MS/UE connected to an MSC/VLR in the same PLMN or routed 
from another network, for example, the PSTN or another PLMN. 

If the call originates from within this same MSC, the chosen B- 
origin will be determined by the OBA parameter in the IMSI 
number series analysis for the originating MS. In our network 
plan, all MO calls are analyzed in B-origin 30. 

If the call originated from another network, the B-origin to analyze 
the MSISDN will be chosen by the BO parameter on the 
incoming route; in our network plan all incoming calls will be 
analyzed in B-origin 0. 

B-number Analysis 

Remember that the B-number analysis is carried out in two stages: 
the pre-analysis and then the analysis of the B-number. 

If the calls originated from within our own PLMN, the number 
dialed can be of the unknown type (BNT=2), but may also be of the 
international type (BNT=1). 

If the call originated from outside our own PLMN, the number 
could be presented in several ways, depending on where it 
originated. 
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If the call came via the PLMN or the PSTN1, both supporting 
ISUP, the number would be presented in the national (BNT=4) or 
maybe in the unknown (BNT=2) format. It could also be presented 
in the international format (BNT=1). Agreements between network 
operators are needed. 

Figure below shows an example of how to define DT needed for 
supporting a call to an MS. 

Note: Origin 22 would also need to be defined; this origin will 
contain all international format numbers received from mobiles. 

115700, 1! 

! **** PRE-ANALYSIS **** ! 

PNBSI : BO=0 , NAPI=1, BNT=1, OBA=l; 

PNBSI : BO=0 , NAPI=1, BNT=2, OBA=0; 

PNBSI :BO=0, NAPI=1, BNT=4, OBA=l; 

PNBSI :BO=30, NAPI=1, BNT=1, OBA=22; 

PNBSI :BO=30, NAPI=1, BNT=2 , OBA=30; 

PNBSI :BO=30, NAPI=1, BNT=4 , OBA=30; 

! 15600 , 1! 

! **** ANALYSIS OF B-NUMBER ****! 

ANBSI :B=0— 03; 

ANBSI : B=0— 032 , RC=3303, L=8, M=l-961, 

ANBSI :B=0-033, RC=3303, L=8, M=l-961, 

Figure 10-3: DT to route call from TSC to MSC Blade 

! cont . ! 


ANBSI :B=l-32, 

RC= 

3303, 

L=7, 

, M=0-961, 

o 

1 

rH 

II 

Q 

cw. 

NW, 

BNT: 

ANBSI :B=l-33, 

RC= 

3303, 

L=7, 

, M=0-961, 

o 

1 

rH 

II 

Q 

cw. 

NW, 

BNT: 

ANBSI :B=1-961 

32, 

RC=3303, 

o 

H 

II 

Hi 

D=l- 

-0, cw, 

NW, 

BNT=1 ; 

ANBSI :B=1-961 

33, 

RC=3303, 

L=10, 

r-H 

II 

Q 

-0, cw, 

NW, 

BNT=1 ; 


ANBSI :B=30-03, L=8; 

ANBSI :B=30-032, RC=3303, CC=1, M=l-961, L=8, D=l-0, BNT=1; 
ANBSI :B=30-033, RC=3303, CC=1, M=l-961, L=8, D=l-0, BNT=1; 


D=l— 0 , 

CW, 

NW, 

BNT=1 

D=l— 0 , 

CW, 

NW, 

BNT=1 


! 15400 , 1 ! 

! **** ROUTING CASE ANALYSIS ****! 

ANRSI : RC=3303 , R=INTRB10, SP=MM1 , CCH=NO; 


Figure 10-4: DT to route call from TSC to MSC Blade 

It can be seen that the pre-analysis directs the analysis of the 
incoming MSISDN to the correct B-origin in the B-number 
analysis table. 
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The important thing to note from the B-number analysis table is 
that the MSISDN is changed to the international format by 
modifying the number and then setting the BNT=1. This is very 
important as the MSISDN is used as a Global Title address for 
SCCP purposes. 

The CW parameter (A-Class Wanted) and the NW parameter (A- 
number Wanted) are specified as parameters available from the 
Application Information for GRI. 

Routing Case 3303 has been chosen for the analysis to transfer it to 
the MSC Blade. The b-number is transferred from TSC to a MSC 
Blade via INTRO Route. The MSC Blades are responsible to query 
the HLR node by using GRI route. 


The figure below shows only part of the number series required for 
routing the MSISDN from TSC Blades to the MSC Blades so that 
they can query the HLR. The number series beginning with 961 3 
4xxxxx are used for several different types of numbers: MSISDNs, 
MSRNs and BLs. This means that the analysis of the number series 
needs to be taken further. Figure below shows this only for B- 
origin 0. B-origins 1 and 30 would need to be considered in a 
similar way. 

115600, 1! 


1 **** 

ANALYSIS OF 

B-NUMBER ****! 





ANBSI 

B=0— 034000, 

RC=25, L=8, M=1 

, BNT=4; 

!MSRN 

TO 

MSCl ! 

ANBSI 

B=0— 034001, 

RC=25, L=8, M=1 

, BNT=4; 

!MSRN 

TO 

MSC1 ! 

ANBSI 

B=0— 034002, 

F=9, L=8, M=l, 

BNT=4 ; 

!MSRN 

TO 

OWN MSC 

ANBSI 

B=0— 034003, 

F=9, L=8, M=l, 

BNT=4 ; 

!MSRN 

TO 

OWN MSC 

ANBSI 

B=0— 034004, 

RC=26, L=8 , M=1 

, BNT=4; 

!MSRN 

TO 

MSC2 ! 

ANBSI 

B=0— 034005, 

RC=2 6 , L=8 , M=1 

, BNT=4; 

!MSRN 

TO 

MSC2 ! 


ANBSI : 

B=0— 03401, 

RC=3303, 

tT* 

II 

00 

M=l— 961 , 

0 

1 

rH 

II 

Q 

CW, 

NW, 

BNT=1 

ANBSI : 

B=0— 03402, 

RC=3303, 

t- 1 

II 

00 

M=l— 961 , 

0 

1 

rH 

II 

Q 

CW, 

NW, 

BNT=1 

ANBSI : 

B=0— 03409, 

RC=3303, 

t- 1 

II 

00 

M=l— 961 , 

0 

1 

rH 

II 

Q 

CW, 

NW, 

BNT=1 


ANBSI : 

B=0— 0341, 

RC=3303 , 

L=8 , 

M=l-961 , 

D 

II 

M 

1 

O 

CW, 

NW, 

BNT=1 

ANBSI : 

B=0— 0342 , 

RC=3303 , 

L=8 , 

M=l-961 , 

D 

II 

M 

1 

O 

CW, 

NW, 

BNT=1 

ANBSI : 

B=0— 0349, 

RC=3303, 

L=8 , 

M=l-961 , 

D 

II 

H 1 
1 

O 

CW, 

NW, 

BNT=1 


Figure 10-5: Further B-number Analysis 

Due to a number series being split between several users, care and 
consideration must be given to this situation when setting up the B- 
number analysis table. 

When the TSC Blades send the call setup to the MSC Blades it will 
be analyzed again in the B-number table in the same entry point i.e. 
in the same b-number origin. But now, the Routing Case should be 
the route to HLR. 
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! 15700 , 1 ! 

!**** pre-ANALYSIS **** ! 

PNBSI : BO=0 , NAPI=1, BNT=1, OBA=l; 

PNBSI:BO=0, NAPI=1, BNT=2 , OBA=0; 

PNBSI :BO=0, NAPI=1, BNT=4 , OBA=l; 

PNBSI :BO=30, NAPI=1, BNT=1 , OBA=22; 

PNBSI :BO=30, NAPI=1, BNT=2 , OBA=30; 

PNBSI :BO=30, NAPI=1, BNT=4 , OBA=30; 

! 15600 , 1 ! 

! **** ANALYSIS OF B-NUMBER ****! 

ANBSI : B=0-03 ; 

ANBSI : B=0-032 , RC=60, L=8, M=l-961, D=l-0, CW, NW, BNT=1 ; 
ANBSI : :B=0-033, RC=60, L=8, M=l-961, D=l-0, CW, NW, BNT=1 ; 

Figure 10-6: Route a Call to GRI 

! cont . ! 


ANBSI :B=l-32, 

o 

VO 

II 

L=7 , 

M=0-961 , 

o 

1 

i— i 

II 

Q 

CW, 

NW, 

BNT= 

ANBSI :B=l-33, 

RC=60 , 

t-* 

II 

-j 

M=0-961 , 

o 

1 

rH 

II 

Q 

CW, 

NW, 

BNT= 


ANBSI :B=1-961 

32, 

RC=60 , 

o 

I 

rH 

II 

Q 

o 

I— 1 

II 

►T 

CW, 

NW, 

BNT=1 

ANBSI :B=1-961 

33, 

RC=60 , 

0 

1 

«H 

II 

Q 

o 

I— 1 

II 

CW, 

NW, 

BNT=1 


ANBSI :B=30-03, L=8; 

ANBSI : B=30-032 , RC=60, CC=1, M=l-961, L=8, D=l-0, BNT=1 ; 
ANBSI : B=30-033 , RC=60, CC=1, M=l-961, L=8, D=l-0, BNT=1 ; 

115400,1! 

!**** ROUTING CASE ANALYSIS **** ! 

ANRSI : RC=60 , R=0GRI3, SP=MM1, CCH=NO; 

ANRSI : RC=3301 , R=INTRT10, SP=MM1 , CCH=NO, ESR=0, ESS=1; 


Figure 10-7: Route a Call to GRI (cont.) 

Note that the INTRO routes defined in the MSC Blades are used to 
route calls to TSC Blades and the TSCs route to external networks 
via ISUP/BICC routes. 
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115600, 1! 

I**** ANALYSIS OF B-NUMBER ****! 


ANBSI : 

B=0-034000, 

RC=25 

, L=8 , M= 

1, BNT=4; 

!MSRN 

TO 

MSC2 ! 

ANBSI : 

B=0— 034001, 

RC=25 

, L=8 , M= 

1, BNT=4; 

!MSRN 

TO 

MSC2 ! 

ANBSI : 

B=0— 034002, 

F=9, 

L=8, M=l, 

BNT=4 ; 

!MSRN 

TO 

OWN MSC! 

ANBSI : 

B=0— 034003, 

F=9, 

L=8, M=l, 

BNT=4; 

!MSRN 

TO 

OWN MSC! 

ANBSI : 

B=0— 034004, 

F=9, 

L=8, M=l, 

BNT=4; 

!MSRN 

TO 

OWN MSC! 

ANBSI : 

B=0— 034005, 

F=9, 

L=8, M=l, 

BNT=4 ; 

!MSRN 

TO 

OWN MSC! 

ANBSI : 

B=0— 034006, 

RC=26 

, L=8 , M= 

1, BNT=4 ; 

!MSRN 

TO 

MSC3! 

ANBSI : 

B=0-034007, 

RC=26 

, L=8 , M= 

1, BNT=4 ; 

!MSRN 

TO 

MSC3! 


ANBSI : 

B=0-03401, 

n 

ii 

O'! 

o 

00 

II 

p 

, M=l— 961 , 

0 

1 

rH 

II 

P 

, cw, 

NW, 

BNT=1 

ANBSI : 

B=0— 03402, 

RC=60, 

00 

II 

p 

, M=l— 961 , 

O 

1 

rH 

II 

P 

, cw, 

NW, 

BNT=1 

ANBSI : 

B=0— 03409, 

. RC=60, 

00 

II 

p 

, M=l— 961 , 

O 

1 

rH 

II 

P 

, cw, 

NW, 

BNT=1 

ANBSI : 

B=0— 0341, 

n 

n 

CT\ 

O 

00 

II 

p 

M=l— 961 , 

0 

1 

rH 

II 

P 

cw. 

NW, 

BNT=1; 

ANBSI : 

B=0— 0342 , 

RC=60 , 

00 

II 

p 

M=l— 961 , 

0 

1 

rH 

II 

P 

cw. 

NW, 

BNT=1; 

ANBSI : 

B=0— 0349, 

RC=60, 

00 

II 

p 

M=l— 961 , 

O 

1 

rH 

II 

P 

cw, 

NW, 

BNT=1; 


Figure 10-8: Further B-number Analysis - All MSC Blades 


Routing Case Analysis 

A Routing Case is chosen to direct the call to a route. In this case 
the route is to select an individual in GRI to carryout the 
interrogation of the HLR. 

In case the call received is from another PLMN or PSTN networks, 
they possibly connected via BICC or ISUP routes. So the first 
blade to analyze the B-numbers received is the TSC. TSC Blades 
need to route this call setup to MSC Blades due to the MSC Blades 
are the only one that can fetch the subscriber location information 
by querying the HLR via GRI routes. 

Next figure shows the Routing Case Analysis data transcript 
required for supporting the selection of the route. From the 
Application Information for the INTRO block the values of the 
FNC, BLAO and DIS parameters can be obtained. The purpose of 
BLAO is an index to correlate the incoming and outgoing routes. 
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! * * * incoming route from MSC/TSC BLADE***! 
EXROI : R=INTRB1I , DETY= INTRO, FNC=2 ; 

EXRBC : R=INTRB1 1 , RGP AR=BLAO— 4 ; 

BLORE : R=INTRB1I ; 

EXROI : R=INTRT1I , DETY= INTRO, FNC=2 ; 

EXRBC : R=INTRT1I , RGP AR=BLAO- 5 , RG=10 ; 

BLORE : R=INTRT1I ; 


j ***OUTGOING ROUTE TOWARDS MSC BLADE**! 
EXROI :R=INTRB10, DETY= INTRO, FNC=1; 

EXRBC : R=INTRB10, RGPAR=DIS-3&BLAO-4 ; 

BLORE : R=INTRB10; 

!*** TRANSIT CALL ***! 

EXROI : R=INTRT10, DETY= INTRO, FNC=1 ; 

EXRBC : R=INTRT10, RGPAR=DIS-2&BLAO-5 , RG=10 ; 
BLORE : R=INTRT10; 

Figure 10-9: INTRO Routes All TSC Blades 


!**** Outgoing route towards TSC blades **** ! 
EXROI : R=INTRT10, DETY=INTRO, FNC=1 ; 

EXRBC : R=INTRT10, RGPAR=DIS-2&BLAO-4 ; 

BLORE : R=INTRT10; 


ANRSI :RC=3301,R=INTRT10, SP=MM1, CCH=NO, ESR=0, ESS=1; 
ANRAI : RC=3301 ; 

!**** incoming route from MSC/TSC blade ****! 

EXROI : R=INTRB1I , DETY= INTRO, FNC=2 ; 

BLORE : R=INTRB1I ; 

EXROI : R=INTRT1I , DETY=INTRO, FNC=2 ; 

EXRBC : R=INTRT1I , RGPAR=BLAO-4 ; 

BLORE : R=INTRT1I ; 

Figure 10-10: INTRO Routes All MSC Blades 


ROAMING INTERROGATION - GATEWAY 
GRI Route Data 


The GRI route is used in two ways, initially to inform the Gateway 
about the version of the MAP message to send to the HLR and 
secondly to inform the Gateway how to continue with the analysis 
on reception of the MSRN or a Call Forward-to-number. The GRI 
route is a software route, pointing to the GRI function block, which 
coordinates the Interrogation of the HLR. 

Once again only the MSC Blades have the GMSC functionality and 
GRI routes are only defined in the MSC blades. 
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EXROI : R=0GRI3, DETY=GRI ; ! STANDARD MAP V3 - INTERROGATION ROUTE ! 

EXRBC : R=0GRI3, BO=8, ! ORIGIN FOR MSRN ANALYSIS ! 

RSV=48 , ! ERICSSON SERVICES ARE SENT IN EXTENSION AREA! 

! 1— BIT0=SPN, 2— BIT1=ICI , 4-BIT2=OIN ! 

! 8-BIT3=DMSISDN, 32-BIT5=MAPV2 ! 

! 48-BIT4&BIT5=MAPV3, 128BIT7=0 USE MAPV2 EXT ! 

CO=0, ! CHARGING ORIGIN FOR ROAMING LEG MSRN ! 

MI SI =30, ! ORIGIN FOR 'FORWARD TO' NUMBER ANALYSIS ! 

MIS2=2, ! CHARGING ORIGIN FOR FORWARD TO NUMBERS ! 

MIS3=15, ! WHICH ORIGINS ARE TO BE USED: ! 

!BO=l, CO=2 , MIS1=4, MIS2=8 ! 

MIS 6=0 ; ! PLMN INDICATOR, OWN SUBS. DEFINED IN MGISI ! 

Application Information: GRI 

Figure 10-11: Definition of the GRI Route 

From the Application Information for the GRI block the values of 
the SP and CCH parameters can be obtained to define the Routing 
Case for GRI routes. Remember that the purpose of SP is to 
determine when and which digits to send to the HLR. There is only 
one MAP message, so all the digits must have been received. 

When defining the GRI route data, it is important to remember that 
the parameter RSV determines the version of the MAP message, 
which is sent to the HLR. The BO and CO parameters are used if 
the returned address is a MSRN or the MIS1 and MIS2 parameters 
are used if the returned address is a Forward-to Number (C#). 

From the previous figure, it can be seen that bit 4 & bit 5 determine 
the standard MAP version to be used. MAP version 3 is required to 
support CAMEL, GSMs IN solution. For a complete understanding 
of RSV and all the other route parameters, it is essential to consult 
the AI for the GRI function block. 

Only one GRI route needs to be defined to be able to route the 
MAP message between the Gateway and the HLR, providing all 
the HLRs have the same MAP signaling requirements. 

The sending of any MAP messages requires the service of SCCP to 
route the message to the terminating node. In this case, the 
Gateway sends the message to the HLR. Remember that it is the 
MSISDN number that is used by SCCP to route the MAP messages 
to the correct HLR. 
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SCCP Analysis 


A description of SCCP has been given in a previous module. The 
purpose of this section is to consider the requirements in the Global 
Title Analysis and the Global Title Routing Case Analysis to 
support the routing of the MAP messages between the Gateway 
and the HLR. The HLR to Gateway will also be considered. 

The Global Title address being analyzed is in fact the MSISDN 
received in the MSC Gateway (GMSC). Remember: A Global Title 
is made up of four parts: Translation Type (TT), Numbering Plan 
(NP), Nature of Address (NA) and Address Information (AI). The 
TT value is a default setting. NP is set by the NAPI value from the 
B -number analysis. NA is set by the BNT value from the B -number 
analysis and AI (in this case) is the MSISDN. 

The Global Titles beginning with 961 3 2, 961 3 3 and 961 3 5 are 
very straight forward as there is no conflict regarding their use. 
However, the Global Titles beginning with 961 3 4 are used as 
Global Titles for: the different node addresses in the PLMN, 
MSISDNs, MSRNs and BLs. That is why the GT analysis looks so 
complicated in Figure 10-6. Thought and care are needed to go into 
these analysis tables. 

The Global Title Routing Case (GTRC) points to the cooperating 
SCCP nodes (a Signaling Point in MTP). The HLR Global Title 
Analysis data transcript can be simplified if the parameter PTERM 
is used in the GTRC analysis to allow routing of SCCP messages 
using the Destination Point Code (DPC). However, there are also 
disadvantages associated with doing this. 


175500, 1! 

! Definition of Global Title Analysis! 


C7GSI : 

TT=0 , 

NP=1, 

NA=4, 

NS 

961 

32, 

GTRC=1; [MSISDN TO 

HLR! 

C7GSI : 

TT=0 , 

NP=1, 

NA=4 , 

NS 

961 

33, 

GTRC=1; [MSISDN TO 

HLR! 

C7GSI : 

TT=0 , 

NP=1 , 

NA=4 , 

NS 

961 

32, 

GTRC=1; [MSISDN TO 

HLR! 

C7GSI : 

TT=0 , 

NP=1 , 

NA=4 , 

NS 

961 

401, 

GTRC=1; [MSISDN TO 

HLR! 

C7GSI : 

TT=0 , 

NP=1, 

NA=4, 

NS 

961 

409, 

GTRC=1; [MSISDN TO 

HLR! 

C7GSI : 

TT=0 , 

NP=1 , 

NA=4 , 

NS 

961 

41, 

GTRC=1; [MSISDN TO 

HLR! 

C7GSI : 

TT=0 , 

NP=1 , 

NA=4, 

NS 

961 

47, 

GTRC=1; [MSISDN TO 

HLR! 

C7GSI : 

TT=0 , 

NP=1, 

NA=4, 

NS 

961 

480, 

GTRC=1; [MSISDN TO 

HLR! 

C7GSI : 

TT=0 , 

NP=1 , 

NA=4 , 

NS 

961 

487, 

GTRC=1; [MSISDN TO 

HLR! 

C7GSI : 

TT=0 , 

NP=1 , 

NA=4 , 

NS 

961 

4880 

, GTRC=1; [MSISDN TO HLR 

C7GSI : 

TT=0 , 

NP=1 , 

NA=4, 

NS 

961 

4887, GTRC=1; [MSISDN TO HLR 


Figure 10-12: DT for Global Title Analysis (1) 


LZT 123 9083 R1 A 


© Ericsson 2009 


- 275 - 


MSC-S R13.1 Blade Cluster Data Transcript 


ERICSSON 


! 75500,1! (cont.) 

! Definition of Global Title Analysis! 


C7GSI 

TT=0, 

NP = 1, 

NA=4 , 

NS 

961 

488800, 

GTRC=1 ; 

!MSC4 TO HLR! 

C7GSI 

TT=0, 

NP = 1, 

NA=4, 

NS 

961 

488810, 

GTRC=2 ; 

!MSC4 TO MSC1 ! 

C7GSI 

TT=0, 

NP = 1, 

NA=4, 

NS 

961 

488811, 

GTRC=3; 

!MSC4 TO MSC3 ! 

C7GSI 

•-3 

II 

o 

NP = 1, 

NA=4 , 

NS 

961 

488812, 

GTRC=7; 

!MSC4 ! 

C7GSI 

•-3 

•-3 

II 

o 

NP = 1, 

NA=4 , 

NS 

961 

489, GTRC=1; IMSISDN TO HLR! 

C7GSI 

•-3 

•-3 

II 

o 

NP = 1, 

NA=4 , 

NS 

961 

49, GTRC=1 ; !MSISDN TO HLR! 

C7GSI 

TT=0, 

NP = 1, 

NA=4, 

NS 

961 

5 , GTRC= 

=1; ! MS I SDN TO HLR! 


Figure 10-13: DT for Global Title Analysis (2) 

You should notice that the number series 961 3 400 is missing from 
the data shown in Figure. This number series belongs to the BL test 
phones. For this reason (as they are fixed to a specific switch) we 
do not need to locate them and hence have no need to define the 
SCCP GT addressing towards the HLR. 


ROAMING NUMBER PROVISION - MSC-S BC 

The MSC/VLR receives the MAP message, Provide Roaming 
Number, and the IMSI will be transferred within the message (in 
TCAP to be precise). 

On reception of this message the MSC-S BC will ensure the MS is 
attached and then allocate and link the MSRN to the IMSI. The 
MSRN is then returned to the HLR via a MAP message. 


SCCP Analysis 


Since the Gateway and the MSC/VLR are physically the same 
node, the GT analysis given before is used to terminate the MAP 
message from the HLR. Also the return GT analysis is already 
defined. 

If several HLRs exist, the GT analysis must be entered for each of 
them. 


Provision of Roaming Number 


The roaming numbers are provisioned by command using the same 
sub-file as that for terminating BL calls. They are both local 
numbers (that is, belong internally to the switch). 
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For the definition of these roaming numbers the MSRNS (Mobile 
Station Roaming Number Series) and MSRN (Mobile Station 
Roaming Number) parameters are used. It is important to 
understand the difference between the two. The MSRN is the 
number that the call is routed by, for example, 961 3 400200 and 
the MSRNS are just a series of MSRN range. The MSRNS 
identifies a MSC-S. In order for the number to be terminated, the 
analysis must be down to the hundreds group level, for example, 
961 3 4002, that is, the MSRN contains two extra digits to that of 
the MSRNS. 

115300, 1! 

I**** ROUTE CHARACTERISTICS **** ! 

EXROI : R=MRNR0 1 , DETY=MRNR ; 

EXROI : R=MRNR02 , DETY=MRNR; 

EXROI : R=MRNR03 , DETY=MRNR; 

EXROI : R=MRNR04 , DETY=MRNR; 

MGEPC : PROP=MSRNHOMETHOD— 0; ! ROAMING / HANDOVER #s! 

MGEPC : PROP =MSRNTCNT IME— 150; [VALIDITY TIME OF #s ! 

MGEPC: PROP=MSRNHNDLIMIT— 20 ; ! #s RESERVED FOR HANDOVER! 

115450, 1! 

I**** DEFINITION OF ROAMING / HANDOVER NUMBERS ****! 

MGRSI :R=MRNR01, MSRNS=961 3 400 2, BLDID=0 ; 

MGRSI :R=MRNR02, MSRNS=961 3 400 3, BLDID=1 ; 

MGRSI :R=MRNR02, MSRNS=961 3 400 4, BLDID=4; 

MGRSI :R=MRNR02, MSRNS=961 3 400 5, BLDID=5 ; 

Figure 10-14: DT to Define the Roaming Numbers Common DT for all 
MSC and TSC Blades (1) 


(cont . ) 


! **** CONNECTION OF ROAMING / HANDOVER NUMBERS ****! 

MGRNI : MSRN= 961 3 400 200 && 961 3 400 299; !MSC and TSC Blades! 
MGRNI : MSRN= 961 3 400 300 && 961 3 400 399; !MSC and TSC Blades! 
MGRNI :MSRN= 961 3 400 400 && 961 3 400 499; !MSC and TSC Blades! 
MGRNI :MSRN= 961 3 400 500 && 961 3 400 599; !MSC and TSC Blades! 


Only in the MSC Blades : 


MGRSC : MSRNS=961 3 400 200 , USAGE=PERM ; 
MGRSC : MSRNS=961 3 400 300 , USAGE=PERM ; 
MGRSC :MSRNS=9 61 3 400 400 , USAGE=PERM ; 
MGRSC :MSRNS=9 61 3 400 500 , USAGE=PERM ; 


! In the MSC Blade 0 ! 
! In the MSC Blade 1! 
! In the MSC Blade 4 ! 
! In the MSC Blade 5 ! 


Figure 10-15: DT to Define the Roaming Numbers MSC and TSC Blades 

( 2 ) 


Figures 11-18 and 11-19 show the commands required to define the 
MSRNs for the entire MSC-S BC. 


The route definition is straightforward, using the EXROI 
commands. See the application information for the MRNR block 
for routes used for either handover or roaming numbers. 
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There are a number of exchange properties to be specified using 
the MGEPC command. The important property is the first one 
listed: MSRNHOMETHOD. This exchange property determines 
how Roaming Numbers and Handover Numbers are to be 
allocated. In this instance (MSRNHOMETHOD-O) both sets of 
numbers are taken from the same group of numbers (that is, the 
pool of available numbers can be used as either handover or 
roaming numbers). The exchange property MSRNHNDLIMIT is 
then available to specify a percentage of the pooled numbers to be 
reserved for handover purposes only. In this example the parameter 
is set to 20%, implying that there will always be 20% of the pooled 
numbers available for handovers. The MSRNHNDTIME 
parameter that the allocated handover number has a lifetime of 150 
seconds after which it would be released. 

Once the exchange properties have been specified, the MSRNS are 
then associated to a route (MGRSI). Each MSRNS points to a route 
and within each route there are 100 numbers. The USAGE 
parameter in the MGRSC command is dependent on the 
MSRNHOMETHOD value. 

Note: See the documents: ‘Mobile Telephony Data Changeable 
Exchange Adaptation’ and the application information for the 
MRNR block for more information regarding the exchange 
properties and the values associated to them. 

This example shows that there are four MSC blades, and each one 
of them handles a specific MSRN range. Just in the correspondent 
MSC Blade will be sent the command MGRSC with the parameter 
USAGE=PERM. In the TSC Blades the command MGRSC is not 
sent. 

ROAMING REROUTING - GATEWAY MSC SERVER 

The MSRN is sent back to the GMSC (function in the MSC 
Blades) via the HLR. The MSRN is then passed to the analysis 
function so that a decision as to whether the MSRN number 
belongs to MSC-S BC (or indeed belongs to any MSC within the 
own PLMN) or to another PLMN. Once this has been established, 
the call can be routed accordingly. 

The ‘Gateway Roaming Rerouting’ (GRR) function block is now 
controlling the call. 


SCCP Analysis 


The GT analysis has already been mentioned during this 
description. The MAP message contains the MSRN. 
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Analysis and Routing of MSRN 

The analysis of the MSRN is determined by the values in the BO 
and MIS3 parameters from the route definition of GRI. Remember 
that the BO parameter is used to direct the MSRN to a particular B- 
origin, while bit 0 of MIS3 is used to determine whether the BO 
parameter should be used. Figure 11-8 shows how the MSRN is 
analyzed and then routed to the correct MSC. 

It is important to remember that all roaming numbers from the GRI 
route are to be analyzed in B-origin 8, in this example, as indicated 
in the route data, parameter BO=8. 

The roaming number could have originated from the MSC4, as 
well as MSC1 or MSC2, or even from another PLMN where a 
roaming agreement exists. 

In all cases the roaming number will be returned in the 
international format, BNT=1. 

115300, 1! 

I**** ROUTE CHARACTERISTICS **** ! 

EXRBC : R=0GRI2, RSV=32, BO=8, CO=l; 

! 15600 , 1 ! 

I**** ROAMING NUMBER ****! 

ANBSI : B=8— 9613400 , L=10 ; 

ANBSI : B=8— 96134000 , RC=3301 , BNT=1 , CC=1 ; 

ANBSI : B=8— 96134001 , RC=3301 , BNT=1 , CC=1 ; 

ANBSI : B=8— 96134002 , F=9, M=3, BNT=4; 

ANBSI : B=8— 96134003 , F=9, M=3, BNT=4; 

ANBSI : B=8— 96134004 , F=9, M=3, BNT=4; 

ANBSI : B=8— 96134005 , F=9, M=3, BNT=4; 

ANBSI : B=8— 96134006 , RC=3301 , BNT=1 , CC=1 ; 

ANBSI : B=8— 96134007 , RC=3301 , BNT=1 , CC=1 ; 


!MSC2 MSRN! 
!MSC2 MSRN! 
! OWN MSRN! 

! OWN MSRN! 

! OWN MSRN! 

! OWN MSRN! 
!MSC3 MSRN! 
!MSC3 MSRN! 


Figure 10-16: Data Transcript to Analyze the MSRN (1) 
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115600, 1! 

!**** ROAMING NUMBER ****! 


ANBSI : B=8— 9613400 , L=10 ; 


ANBSI : B=8— 96134000 , RC=2 
ANBSI :B=8— 96134001, RC=2 
ANBSI : B=8— 96134002 , F=9, 
ANBSI : B=8— 96134003 , F=9, 
ANBSI :B=8— 96134004, F=9, 
ANBSI : B=8— 96134005 , F=9, 
ANBSI : B=8— 96134006 , RC=2 
ANBSI :B=8— 96134007, RC=2 


i,BNT=l, CC=1; 

!MSC2 

MSRN! 

i , BNT=1 , CC=1 ; 

!MSC2 

MSRN! 

M=3, BNT=4; 

! OWN 

MSRN! 

M=3, BNT=4; 

! OWN 

MSRN! 

M=3, BNT=4; 

! OWN 

MSRN! 

M=3, BNT=4; 

! OWN 

MSRN! 

;,BNT=1, CC=1; 

!MSC3 

MSRN! 

;,BNT=1, CC=1; 

!MSC3 

MSRN! 


115400, 1! 

I**** ROUTE ANALYSIS ****! 
ANRSI : RC=25, R=MSC20, SP=MM1 ; 
ANRSI : RC=2 6 , R=MSC30 , SP=MM1 ; 


Figure 10-17: Data Transcript to Analyze the MSRN (2) 

If the roaming number belongs to MSC1, MSC2 or to another 
PLMN then the call will be routed by way of the routing case. This 
also means that the MSC blade routes via INTRO route to TSC and 
then TSC blades route via external routing case (external to MSC-S 
BC). 

If the roaming number belongs to MSC-S BC then the analysis 
continues in origin 9. 


RCF Charging 


It is possible to charge for this RCF leg (Roaming Call Forward). 
For charging to take place, a TT record needs to be generated, 
which can only happen if a charging case is specified in the B- 
number analysis. The CO parameter, specified in the GRI route 
data, can then be used as branch parameter within the charging 
analysis itself with a Charging Case of 1. 
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ANALYSIS OF MSRN IN RECEIVING MSC/VLR 


115600, 1! 

I**** b-NUMBER ANALYSIS ****! 


ANBSI :B=0-034002, 

CT> 

II 

h 

IT 1 

II 

00 

, M=l, 

BNT=4 

ANBSI :B=0-034003, 

CT> 

II 

t-< 

II 

00 

, M=l, 

BNT=4 

ANBSI :B=0-034004, 

CT> 

II 

II 

00 

, M=l, 

BNT=4 

ANBSI :B=0-034005, 

CT> 

II 

h 

II 

00 

, M=l, 

BNT=4 

ANBSI :B=l-34002, 

II 

VO 

It 1 

II 

-J 

BNT=4 ; 


ANBSI :B=l-34003, 

ii 

L=7 , 

BNT=4 ; 


ANBSI :B=l-34004, 

II 

U3 

IT 1 

II 

-J 

BNT=4 ; 


ANBSI :B=l-34005, 

II 

IT 1 

II 

-J 

BNT=4 ; 



I**** MOBILE TERMINATING **** ! 

ANBSI : B= 9-34002 , MTE, D=3— 0 , L=7 ; 

ANBSI : B= 9-34003 , MTE, D=3-0 , L=7 ; 

ANBSI : B= 9-34004 , MTE, D=3-0 , L=7 ; 

ANBSI :B= 9-34005, MTE, D=3-0,L=7; 

Figure 10-18: DT to Terminate the MSRN 

116000, 1! 

I**** TELECOMMUNICATION SERVICE ANALYSIS ****! 

MGTEI : TEC=THY, TSC=1, CRT=FR-FR, PSCVL=FRV1&FRV2 ; 

MGTEI : TEC=THY, TSC=1, CRT=DHR— DHRC , PSCVL=FRV1&FRV2&HRV1; 
MGTEI :TEC=THY, TSC=1, CRT=DFR— DFRC , PSCVL=FRV1&FRV2&HRV1; 

MGTEI :TEC=AFX3, TSC=5, TRI=T; 

MGTCI : TSC=1 , WSIG=NOIS, TBP=NO, TPI=YES, NOTE="THY" ; 

MGTCI : TSC=5, WSIG=ISPR, TBP=YES, TPI=NO, NOTE="AFX3", TCL=6; 


115300, 1! 

I**** ROUTE CHARACTERISTICS ****! 

EXROI : R=MTB, DETY=MTB; ! ROUTE FOR MOBILE TERMINATING! 

EXRBC : R=MTB , BO=90, MIS3=0; IB-ORIGIN USED FOR MT CHARGING! 


Figure 10-19: Telecommunication Service Analysis 
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Analysis of MSRN 


The roaming number can be received into MSC4 in one of two 
ways. If the GMSC and MSC/VLR are the same node, then the 
roaming number will have come from B-origin 8. If the roaming 
number has been routed from another GMSC, then the analysis will 
take place in B-origin 0 or 1. In either case the roaming number 
will be sent to B-origin 9 for the number to be terminated. 

In B-origin 9, the analysis is terminated with the MTE parameter, 
which means a Mobile TErminating call. When the MTE parameter 
is used, the national MSRNS needs to be generated. The country 
code, in this example 961, would be generated by the MTRAN. 

Note: The MTE parameter is sent in all MSC and TSC Blades. 

Telecommunication Service Analysis 

When the analysis of the roaming number has been completed, the 
telecommunication service analysis takes place to analyze the 
requested service. This data transcript will already have been 
completed to allow the mobile originating call to take place (see 
module 8 for information regarding the telecommunication service 
analysis). 


MT Charging 


To allow the call to be charged from the MSC to the MS, referred 
to as the MT (Mobile Terminating) leg or airtime charging, the 
route data for MTB needs to identify a B-origin. This is done with 
the BO parameter. BO is only active if bit 0 of the MIS3 parameter 
is set to 1 (MIS3=1). In the above example airtime charging does 
not take place, since the MIS3=0. 

The B -number that is sent to this table to be analyzed is always in 
the international format. It is here, in B-origin 90, that a charging 
case would be generated. 
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1 1 Announcement in MSC-S BC 


Objectives 



Create the exchange data for announcements in the MSS 
architecture. 


■ Understand the phrase of announcements. 

■ Configure access to announcement and the route data. 

■ Write DT example of announcements 



Figure 11-1. Objectives 
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ANNOUNCEMENTS 

Announcements are used to give a subscriber some information as 
to why a call has not reached through connection or why it may 
have terminated prematurely. 

An announcement consists of one or more phrases. A phrase may 
consist of tones or words. They are stored on the RAM or the 
EPROM memory in the announcement system. Each phrase is 
assigned a unique number. An announcement may consist of up to 
32 phrases concatenated together. 

An announcement is any kind of speech data, which is to be 
announced. Each announcement can be split into one or more 
phrases. 

An announcement can consist of fixed and variable phrases. An 
example is shown in the figure below. 



ANN: Announcement 
FP: Fixed Phrase 
VP: Variable Phrase 

Figure 11-2. Announcement composition 


PHRASES 


There are two categories of phrases: 

1. Pre-recorded phrases 

2. Recordable phrases 


LZT 123 9083 R1 A 


© Ericsson 2009 


- 285 - 


MSC-S R13.1 Blade Cluster Data Transcript 


ERICSSON 


Pre-recorded Phrases 

There are three types of pre-recorded phrases: 

• Fixed 

• Silent 

• Variable 


Fixed Phrase 

A fixed phrase is a phrase whose content is fixed at the production 
stage. The phrase content cannot be changed, once it is in service. 
This type of phrase is used when a high degree of availability of a 
particular phrase is needed. The following is an example of a fixed 
phrase: 

"The number you have dialed is out of service" 

Fixed phrase numbers range from 6-4095 & 34096-62767. 

Silent Phrase 

A silent phrase number in a message indicates the amount of 
silence required in that message. All silent phrase numbers are of 
the format 53XX. So, if 4.5sec of silence is required in a message, 
then phrase number 5345 should be used. This phrase number will 
be converted by the announcement system into the required amount 
of silence by the concatenation of the correct multiples of 4 smaller 
silence phrases. 

Silent phrase numbers range from 5300-5399 

Variable Phrase 


A variable phrase is a phrase whose meaning is determined in the 
exchange, but its actual content is determined on a per call basis by 
data sent from the user function. An example of a message using 
variable phrases is: 

"Your call has lasted XX minutes and YY seconds" 

Where XX and YY are the variable parts. 
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For example, if a call lasted 5 minutes and 10 seconds, the numeric 
values "5" and "10" will be supplied by the user function. These 
will be translated into the required fixed phrase numbers to be used 
in the complete message: 

"Your call lasted five minutes and ten seconds" 

Variable phrase number range from 6001-6099 

A Recordable phrase is a phrase whose contents are determined by 
authorized personnel or subscribers using a recording procedure. 
The authority is based on a pin-code, which is verified in the 
exchange. Recordable phrases are stored in RAM memory in the 
announcement system. Recordable phrases are used to create 
messages, which need to be updated frequently. The following is an 
example of a recordable phrase: 

"The weather forecast for today is warm and sunny" 

Recordable phrase numbers range from 10000-26382. 

Message Composition 

In the terminology of the M-MGw a message composition is a 
message which is composed of a sequence of other messages. One 
or more basic messages, variable messages and other message 
compositions may be the constituents of a message composition. 

In general the concept of message composition corresponds to the 
concept of announcement in the MSC Server with a slight 
difference; in fact a message composition can contain further 
message compositions while an announcement in MSC Server can 
only include fixed and variable phrases. 

Below an example figure of decomposing messages. 
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BM 



VM: Variable Message 


Figure 11-3. Message composition 


ACCESSING ANNOUNCEMENTS 

Accessing announcements corresponds to accessing a route to 
which those announcements are tied in exchange data. 

For MSS network, which is layered architecture network, 
announcements are handled in MGW in stead of M-AST in MSC. 
The announcement data flow in MSC-S as shown in figure below. 



Figure 1 1-4. Announcement data flow in MSS 

In order to have a consistent configuration for announcements, the 
announcement code in the MSC Server shall match the identifier of 
the corresponding message in the M-MGw. 

In case of fixed announcements, the announcement code in the 
MSC Server shall correspond to the identifier of a message 
composition in the M-MGw not including variable messages. 
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In case of variable announcements, the announcement code in the 
MSC Server must correspond either to the identifier of a variable 
message in the M-MGw or to the identifier of a message 
composition including variable messages. 



MSC Server 

M-MGw 

Fixed ann. 

Announcement code 

Message Composition Id 
or 

Basic Message Id 

Variable ann. 

Announcement code 

Message Composition Id. 
or 

Variable Message Id 


Table 11-1. Information to be kept aligned between MSC Server and M- 
MGw (Ericsson Profile) 


It is recommended that the announcements should start with a 
period of silence of about 1 sec. Reason for this is that some 
handsets need some time to become ready to receive audio signals 
after receiving an Alerting Message from the network; if the 
announcement is immediately started with speech the initial part 
might not be heard, especially at call set-up. 

There are two key function blocks in above data flow, which are 

• TCIA:it is used to activate sending or recording of an 
announcement through B-number and routing case analysis 

• AUIF: is an interface block between the announcement user 
functions and announcement systems. It is used by a user 
function when it wishes to: 

o send an audible message to a subscriber. 

o receive digits keyed in by a subscriber. 

o record an audible message from a subscriber. 

o duplicate an audible message from or to another 
system. 

In order to route the call to announcement, the announce code 
(ANNC) can either be defined as called party number in B-number 
analysis table or be defined as the parameter MB (modification of B- 
number) which is need to be defined in route data via EXRBC (See 
Application Information of block TCIA for further information) 

Note, that the defined announcement code in route data has priority 
over the included announcement code in the B-number if an 
announcement code is defined in both. 
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Announcement Routes 

There are 3 different types of routes in the announcement system. 

1. Listening route 

2. Recording route 

3. Main route 

Listening and Recording routes are used for the administration of 
announcement related data. One listening route corresponds to one 
recording route with the same phrase number. 

Main routes are used for the administration of the devices that 
connect the announcement system to the Group Switch, which are 
of ASDH3 type. 

These different types of routes are distinguished by assigning them 
different Function Code (FNC) values in the route definition. 

The following FNC values are possible: 

• FNC =1 for Main route 

An announcement route that allows listening and recording routes 
to be connected to devices 

• FNC =2 for listening route 

An announcement route that is used to send announcements to 
listeners. The route is seized via the Announcement Unit User 
Interface (AUIF). The announcements may contain fixed phrases, 
silent phrases, variable phrases and recordable phrases. 

• FNC=3 for recording route 

An announcement route that is used to record the contents of a 
recordable phrase. The route is seized via the Announcement Unit 
User Interface (AUIF ). 

• FNC=4 for copy route 

An announcement route that is used to record the contents of a 
fixed phrase. The route is seized via the Announcement Unit User 
Interface(AUIF ). 
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DT EXAMPLE OF ANNOUNCEMENT IN MSS 

For MSS network, which is layered architecture network, 
announcements are handled in MGW in stead of M-AST in MSC. 
That is to say, M-AST will not exit in MSC. So it is no need to 
define M-AST hardware DT, main route, and recording route as 
described previously. The definition is divided into 3 steps: 


ANNOUNCEMENT INTERFACE DEFINITION. 


Firstly define announcement interface. The example is shown in 
figure below: 


!* TCIA Traffic Control Interface towards ANS *! 


EXROI :R=TCIAL1, 
EXRBC : R=TCIAL1 , 
EXROI :R=TCIAR1, 
EXRBC :R=TCIAR1, 
! * AUIF 
EXROI :R=AUIF, 


FNC=1 ; ! LISTINING ROUTE ! 
FNC=2 ; ! RECORDING ROUTE ! 


DETY=TCIA, 

RSV=516; 

DETY=TCIA, 

RSV=516; 

Announcement Unit User Interface Function *! 
DETY=AUIF ; 


BLORE : R=TCIAL1 ; 
BLORE : R=TCIAR1 ; 
BLORE : R=AUIF ; 


Figure 1 1 -5. Announcement Interface Definition 


ROUTING CASE ANALYSIS DEFINITION 


Next step is defining routing case analysis. In the example after 
routing case analysis, the listening route can be obtained. 

! * ROUTING CASE FOR AUIF ANNOUNCEMENTS *! 

ANRSI : RC=94 , R=TCIAL1, CCH=NO, SP=MM1; ! LISTENING! 

ANRSI : RC=95 , R=TCIAR1, CCH=NO, SP=MM1; ! RECORDING! 

ANRAI :RC=94&95; 

Figure 1 1 -6. Routing Case Analysis Definition 


LZT 123 9083 R1 A 


© Ericsson 2009 


- 291 - 





MSC-S R13.1 Blade Cluster Data Transcript 


ERICSSON 


B-NUMBER ANALYSIS DEFINITION 

Finally , B-number analysis definition need to be defined. The 
example is shown in figure below. 

! * B-NUMBER ANALYSIS FOR ANNOUNCEMENTS *! 

! ANNC=3101 The subscriber is absent, please call again later! 

! ANNC=3102 Please hold on, your call is forwarded to another number! 

! ANNC=3103 The number is not available from this telephone ! 

! ANNC=3200 The subscriber can not be reached for the moment. Please try again later ! 

! ANNC=3201 The subscriber can not take your call right now, please try again later! 

! ANNC=3202 The subscriber you have dialled have changed number ! 

! ANNC=3404 Your call is waiting, please hold ! 

! ANNC=3405 Your call is being put on hold ! 


ANBSI : B=99-3 , L=4, RC=94; ! EOS ACCESS TO ANNC LISTENING ROUTES! 

ANBSI :B=99-8, L=4, RC=95; ! EOS ACCESS TO ANNC RECORDING ROUTES! 

Figure 11-7. B- Number Analysis Definition 
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